Skip to content

bundle: clearer errors for bundle (re)naming and first deploy - #7005

Draft
janniklasrose wants to merge 2 commits into
mainfrom
janniklasrose/bundle-rename-error-message
Draft

janniklasrose wants to merge 2 commits into
mainfrom
janniklasrose/bundle-rename-error-message

Conversation

@janniklasrose

Copy link
Copy Markdown
Member

Why

The bundle's workspace root path is derived from bundle.name. Two deploy-time situations around (re)naming a bundle produce confusing output today:

  1. Renaming to a name whose root already holds another deployment's state fails with the opaque lineage mismatch in state files, which gives no hint that another bundle is deployed at that root.
  2. A fresh deploy (a new bundle, or a rename to an empty root) silently creates a brand-new deployment. Users don't realize that renaming a bundle is effectively a new deployment that does not adopt the old resources — so they're surprised when matching resources are created again (or hit already exists).

What

  • Replace the lineage mismatch in state files error with an explanation of the likely cause (another bundle deployed to the same root path, or a redeploy from a different machine/checkout after a destroy) and the fix (bundle.name / workspace.root_path). The existing Available state files: detail is unchanged.
  • On the first deploy to a root (no prior state), print a one-line notice:
    Creating a new deployment of bundle "<name>" at <root_path>
    It's gated like the per-resource action lines, so -q/-qq silence it.

Notes for review

  • Large golden churn is expected: the first-deploy notice appears on every fresh bundle deploy / pipelines deploy.
  • Two goldens were restored by hand instead of regenerated, because the local suite couldn't produce clean output for them (reasons unrelated to this change); each got only the single notice line:
    • bundle/deploy/mlops-stacks: the vendored-template materialization/cleanup fails in this sandbox, so the deploy output didn't regenerate.
    • bundle/deploy/immutable-permissions-change: regenerating reordered the non-deterministic per-resource lines; reverted that and added only the notice.

This pull request and its description were written by Isaac.

janniklasrose and others added 2 commits October 9, 2026 12:59
Both messages concern the bundle's root path, which is derived from
bundle.name:

- Replace the opaque "lineage mismatch in state files" error with the
  likely cause (another bundle deployed to the same root path, or a
  redeploy from a different machine or checkout after a destroy) and how
  to resolve it.
- On the first deploy to a root (no prior state), print a notice that a
  new, independent deployment is being created, so renaming a bundle -
  which changes the root path - reads as a new deployment.

Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
@github-actions github-actions Bot added DABs DABs related issues PyDABs labels Oct 9, 2026
@eng-dev-ecosystem-bot

Copy link
Copy Markdown
Collaborator

Integration test report

Commit: 730d30f

Run: 37934123237

Env ✅​pass 🙈​skip Time
✅​ aws linux-2core-8gb 339 45 10:27
✅​ aws-windows-latest-4core-16gb 287 61 4:52
✅​ azure linux-2core-8gb 338 45 6:03
✅​ azure-windows-latest-4core-16gb 286 61 5:05
✅​ gcp linux-2core-8gb 339 45 10:02
✅​ gcp-windows-latest-4core-16gb 287 61 5:52
Top 8 slowest tests (at least 2 minutes):
duration env testname
7:06 aws linux-2core-8gb TestAccept/bundle/config-remote-sync/multiple_resources/DMS=true
6:32 aws linux-2core-8gb TestAccept/bundle/config-remote-sync/multiple_resources/DMS=
6:19 gcp linux-2core-8gb TestAccept/bundle/config-remote-sync/multiple_resources/DMS=
5:50 gcp linux-2core-8gb TestAccept/bundle/config-remote-sync/multiple_resources/DMS=true
4:25 gcp-windows-latest-4core-16gb TestAccept
3:44 azure-windows-latest-4core-16gb TestAccept
3:35 aws-windows-latest-4core-16gb TestAccept
2:07 aws linux-2core-8gb TestAccept

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DABs DABs related issues PyDABs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants