Uh oh!
There was an error while loading. Please reload this page.
Fix deployment failing when app is in DELETING state - #4102
Conversation
varundeepsaini
commented
Dec 4, 2025
Hey @andrewnester |
denik
commented
Dec 5, 2025
@varundeepsaini thanks for the PR. Generally, any waiting that is resource-related should be done in the deployment DAG (so in bundle/direct/dresources for direct engine & terraform provider for terraform engine) (for performance). I don't see why this case would warrant an exception. |
d3cc9f2 to
a495c5aCompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
An authorized user can trigger integration tests manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
Hey @andrewnester |
varundeepsaini
commented
Dec 18, 2025
@andrewnester bump ^^ |
Commit: 0f31f50
25 interesting tests: 14 KNOWN, 6 RECOVERED, 4 FAIL, 1 SKIP
Top 22 slowest tests (at least 2 minutes):
|
Uh oh!
There was an error while loading. Please reload this page.
eng-dev-ecosystem-bot
commented
Dec 22, 2025
Commit: d79a4c2
38 interesting tests: 14 KNOWN, 13 FAIL, 6 RECOVERED, 4 flaky, 1 SKIP
Top 50 slowest tests (at least 2 minutes):
|
denik
commented
Dec 29, 2025
@varundeepsaini@andrewnester I left a comment on the ticket, please check #4006 (comment) |
## Description Moves app deletion wait from `DoDelete` to `DoCreate`, and only retries when appropriate. ## Changes - On `RESOURCE_ALREADY_EXISTS` error, check app state via GET before retrying - Only retry if the app is in `DELETING` state or was just deleted (404) - Return hard error if app exists in any other state (e.g., `ACTIVE`) ## Why? - Handles apps deleted externally (manual deletion), not just via `bundle destroy` - Avoids unnecessary latency in destroy operations - Fixes the issue at the point of failure (create, not delete) - Prevents infinite retries when app exists and is not being deleted Follow up to #4102, addresses feedback from #4006. --------- Co-authored-by: Denis Bilenko <denis.bilenko@databricks.com>
Fixes: #4006 ## Changes Added a wait for apps in `DELETING` state to be fully deleted before deployment proceeds. ## Why Deployment fails when an app is in `DELETING` state because the app still exists but is being removed. This adds a pre-deployment check that polls and waits (up to 5 minutes) for apps to finish deleting.
## Description Moves app deletion wait from `DoDelete` to `DoCreate`, and only retries when appropriate. ## Changes - On `RESOURCE_ALREADY_EXISTS` error, check app state via GET before retrying - Only retry if the app is in `DELETING` state or was just deleted (404) - Return hard error if app exists in any other state (e.g., `ACTIVE`) ## Why? - Handles apps deleted externally (manual deletion), not just via `bundle destroy` - Avoids unnecessary latency in destroy operations - Fixes the issue at the point of failure (create, not delete) - Prevents infinite retries when app exists and is not being deleted Follow up to #4102, addresses feedback from #4006. --------- Co-authored-by: Denis Bilenko <denis.bilenko@databricks.com>
Fixes: #4006
Changes
Added a wait for apps in
DELETINGstate to be fully deleted before deployment proceeds.Why
Deployment fails when an app is in
DELETINGstate because the app still exists but is being removed. This adds a pre-deployment check that polls and waits (up to 5 minutes) for apps to finish deleting.