1) When doing a stack update, we now delete a previously existing stack if it's in ROLLBACK_COMPLETE state (ie. a previous stack create action couldn't complete so it rolled back).
When doing a stack update, we now return immediately if an existing stack is in CREATE_FAILED state (ie. a previous stack create action couldn't complete and rollback is disabled)
2) Stack events
We were using the AWS-SDK's resource waiter to poll for stack events until the stack entered an end state. Unfortunately, the first time the waiter checks resource status after we issue a create, update or delete, the stack is often still in the end state from a previous change so the waiter stops polling before the stack enters a new in progress state. I've switched to a simpler mechanism of polling in a loop for now.
Sorry for the two intertwined changes in this PR.
1) When doing a stack update, we now delete a previously existing stack if it's in ROLLBACK_COMPLETE state (ie. a previous stack create action couldn't complete so it rolled back).
When doing a stack update, we now return immediately if an existing stack is in CREATE_FAILED state (ie. a previous stack create action couldn't complete and rollback is disabled)
2) Stack events We were using the AWS-SDK's resource waiter to poll for stack events until the stack entered an end state. Unfortunately, the first time the waiter checks resource status after we issue a create, update or delete, the stack is often still in the end state from a previous change so the waiter stops polling before the stack enters a new in progress state. I've switched to a simpler mechanism of polling in a loop for now.