direct: treat DELETING apps as gone during plan#6045
Merged
Conversation
App DELETE is fire-and-forget: the app sits in ComputeState=DELETING for up to ~20 minutes and a GET returns it (not 404), so a second delete returns 400. Add an optional IResource.IsGone(remote) hook, consulted in the plan Delete branch, and implement it for apps to mark the entry Gone so apply cleans up state without re-issuing the delete. Re-enables app.yml.tmpl in the delete_idempotent/destroy_idempotent invariant tests. Co-authored-by: Isaac
Assert IsGone directly on the remote returned after delete: true for a DELETING app (the state the planner short-circuits on), false for the noop permissions/grants case where the resource genuinely still exists. Co-authored-by: Isaac
Collaborator
Integration test reportCommit: cdf6cfb
8 interesting tests: 4 RECOVERED, 4 SKIP
Top 3 slowest tests (at least 2 minutes):
|
andrewnester
approved these changes
Jul 24, 2026
janniklasrose
approved these changes
Jul 24, 2026
Comment on lines
+195
to
+197
| // The resource is in a transient terminal-teardown state (e.g. an app in | ||
| // DELETING) that a GET still returns but a second delete would reject. | ||
| // Treat it as gone: apply cleans up state without re-issuing the delete. |
Contributor
There was a problem hiding this comment.
comment is too specific for generic adapter.IsGone
Suggested change
| // The resource is in a transient terminal-teardown state (e.g. an app in | |
| // DELETING) that a GET still returns but a second delete would reject. | |
| // Treat it as gone: apply cleans up state without re-issuing the delete. | |
| // The resource considered gone per its adapter (e.g. in teardown state) |
Contributor
Author
There was a problem hiding this comment.
I think it's good to always include specific examples to support generic statement.
Especially where this is the one and only reason for this adapter method to exist.
Contributor
There was a problem hiding this comment.
it's not always in transient terminal-teardown state though, right? adapter.IsGone can mean something else too, and then this comment won't get updated in the future if a different resource adds the IsGone implementation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
App DELETE is fire-and-forget: the app sits in ComputeState=DELETING for up to ~20 minutes and a GET returns it (not 404), so a second delete returns 400 and breaks delete/destroy idempotency.
Add an optional IResource.IsGone(remote) hook, consulted in the plan Delete branch, and implement it for apps to mark the entry Gone so apply cleans up state without re-issuing the delete. Re-enables app.yml.tmpl in the delete_idempotent/destroy_idempotent invariant tests (added in #6009).