I have no extra information, but if we assume author's theoretical implementation:
> 1 get the current value of dynamodb.us-east-1.api.aws
> 2 set rollback.ddb.aws to the value from step 1
> 3 set dynamodb.us-east-1.api.aws to the new value
.. then I'd totally abort the whole process if step 1 fails. Updating global DNS name is a potentially dangerous step; any unexpected errors should stop it. Having the record which plan says "valid" be actually "invalid" definitely counts for such expected error. After all, what if we are looking at the wrong record, or the plan is somehow bogus? Doing nothing is safer...
So I would not call this part "a bad programming practice" at all, just a sensible precaution in a high-risk system.
On the other hand, the loose locking mechanism that allows two updates to run simultaneously? That's a bug all right..
> 1 get the current value of dynamodb.us-east-1.api.aws
> 2 set rollback.ddb.aws to the value from step 1
> 3 set dynamodb.us-east-1.api.aws to the new value
.. then I'd totally abort the whole process if step 1 fails. Updating global DNS name is a potentially dangerous step; any unexpected errors should stop it. Having the record which plan says "valid" be actually "invalid" definitely counts for such expected error. After all, what if we are looking at the wrong record, or the plan is somehow bogus? Doing nothing is safer...
So I would not call this part "a bad programming practice" at all, just a sensible precaution in a high-risk system.
On the other hand, the loose locking mechanism that allows two updates to run simultaneously? That's a bug all right..