provider/aws: More noisy about aws_security_group consistency issues #9719
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It appears, based on the report in #6991, that the EC2 API is being inconsistent in reporting that a security group exists shortly after it has been created; we've seen Terraform get past the "Waiting for
Security Group to exist" step but then apparently detect that it's gone again once we get into the Update function.
This is not a fix for the issue, but it does make Terraform complain more loudly should the situation arise:
Update
function, as I suspect is the case for bug Resource does not have attribute 'id' for variable #6991, we will treat this as a fatal error and bail out with partial state, whereas before Terraform would lose track of the security group altogether. This seems more correct in any case, since it's not theUpdate
function's job to refresh the state.Read
function, we will still drop it from the state but we'll first generate a debug log acknowledging that this is happening, to give us more to work with when debugging should this issuecontinue to arise for those who have seen it so far.