Fix deployment failing when app is in DELETING state#4102
Merged
andrewnester merged 6 commits intodatabricks:mainfrom Dec 22, 2025
Merged
Fix deployment failing when app is in DELETING state#4102andrewnester merged 6 commits intodatabricks:mainfrom
andrewnester merged 6 commits intodatabricks:mainfrom
Conversation
varundeepsaini
requested review from
andrewnester,
anton-107,
denik,
pietern and
shreyas-goenka
as code owners
Contributor
Author
|
Hey @andrewnester |
Contributor
|
@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. |
varundeepsaini
force-pushed
the
fix/app-deleting
branch
from
d3cc9f2 to
a495c5a
Compare
Contributor
Author
andrewnester
reviewed
Dec 8, 2025
|
An authorized user can trigger integration tests manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
Contributor
Author
|
Hey @andrewnester |
Contributor
Author
|
@andrewnester bump ^^ |
Collaborator
|
Commit: 0f31f50
25 interesting tests: 14 KNOWN, 6 RECOVERED, 4 FAIL, 1 SKIP
Top 22 slowest tests (at least 2 minutes):
|
andrewnester
approved these changes
Dec 22, 2025
Collaborator
|
Commit: d79a4c2
38 interesting tests: 14 KNOWN, 13 FAIL, 6 RECOVERED, 4 flaky, 1 SKIP
Top 50 slowest tests (at least 2 minutes):
|
Contributor
|
@varundeepsaini @andrewnester I left a comment on the ticket, please check #4006 (comment) |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 2, 2026
## 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>
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.
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.