Classify uv sync resolver failures as E_PROVISION_CONFLICT - #6666
Merged
Merged
Conversation
Collaborator
Integration test reportCommit: 3b84e07
Top 7 slowest tests (at least 2 minutes):
|
rugpanov
marked this pull request as ready for review
September 14, 2026 10:28
rugpanov
force-pushed
the
setup-local/provision-conflict-sync
branch
from
September 14, 2026 11:05
a1e3c5b to
2607318
Compare
misha-db
approved these changes
Sep 14, 2026
setup-local only reported E_PROVISION_CONFLICT for direct-pin conflicts
caught pre-sync by the merge phase (W_USER_CONSTRAINT_CONFLICT). Transitive
dependency conflicts are only discoverable by uv's resolver, so they failed
`uv sync` with a generic E_PROVISION and received no conflict-specific
handling — even though they are the more common conflict shape.
Classify a uv sync failure whose stderr is uv's resolver-failure headline
("no solution found" / "are unsatisfiable") as E_PROVISION_CONFLICT, so both
conflict shapes are attributed alike. Other sync failures (network, wheel
build, interpreter) stay generic E_PROVISION.
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
uv reuses its 'No solution found ... unsatisfiable' resolver banner for some non-conflict failures (missing package, offline index, requires-python), so those are also classified E_PROVISION_CONFLICT. Document this as accepted (coarse hint; verbatim uv stderr is preserved in the message) and reconcile the pre-sync merge-gate comment, which now cross-references the sync-phase path. Co-authored-by: Isaac <no-reply@databricks.com>
An offline cache miss (uv --offline / UV_OFFLINE) carries uv's resolver banner
('No solution found ... was not found in the cache') but is a reachability
problem, not a dependency conflict. uv also prints a 'network was disabled'
hint in that case; early-return false on it so the failure stays E_PROVISION.
This kills the one reachability edge that leaked into the conflict banner
(other transport failures already fail before the resolver with different
wording). Nonexistent-package and requires-python mismatches remain classified
as conflicts (user-actionable dependency problems).
Co-authored-by: Isaac <no-reply@databricks.com>
rugpanov
force-pushed
the
setup-local/provision-conflict-sync
branch
from
September 14, 2026 12:30
b60f82c to
3b84e07
Compare
Collaborator
Integration test reportCommit: 9022760
551 interesting tests: 413 FAIL, 122 MISS, 8 flaky, 7 KNOWN, 1 SKIP
Top 50 slowest tests (at least 2 minutes):
|
janniklasrose
pushed a commit
that referenced
this pull request
Sep 15, 2026
## Why `environments setup-local` reported `E_PROVISION_CONFLICT` only for **direct-pin** conflicts caught before `uv sync` by the merge phase (`W_USER_CONSTRAINT_CONFLICT`). A conflict in the **transitive** dependency graph is only discoverable by uv's resolver, so it failed `uv sync` with a generic `E_PROVISION` and got no conflict-specific handling — even though transitive conflicts are the more common shape. ## What Classify a `uv sync` failure as `E_PROVISION_CONFLICT` when uv's stderr is its dependency-resolution failure (`No solution found` / `unsatisfiable`), so both conflict shapes carry the same code. Other sync failures (network, wheel build, interpreter) stay `E_PROVISION`. Layered on top of — not replacing — the pre-sync merge check. ## Testing - Unit (`TestIsUvResolutionConflict`, `TestProvisionClassifiesResolutionConflict`): resolver stderr → `E_PROVISION_CONFLICT`; unrelated stderr (incl. offline cache-miss) → `E_PROVISION`. - Acceptance (`acceptance/localenv/provision-conflict-sync`): a fake uv fails `uv sync`; JSON output shows `E_PROVISION_CONFLICT` at the provision phase with **no** `W_USER_CONSTRAINT_CONFLICT` warning — distinguishing it from the merge-phase path. - Not covered on Windows: the acceptance test uses a bash fake-uv, so it is gated `GOOS.windows=false` (same as `acceptance/cmd/psql`); the unit tests are cross-platform. ## Reviewer notes - **Transport failures already excluded:** a VPN block / unreachable index / DNS failure fails *before* the resolver with different wording (`Failed to fetch`, `Connection refused`), so it stays `E_PROVISION`. The one reachability case that carries the resolver banner is an offline cache-miss (`--offline`/`UV_OFFLINE`), which also prints a `network was disabled` hint — explicitly excluded. - **Remaining accepted imprecision:** a genuinely nonexistent/typoed package or a requires-python mismatch also carry the `No solution found … unsatisfiable` banner and are reported as `E_PROVISION_CONFLICT`. Accepted — both are user-actionable dependency problems, uv exposes no machine-readable signal to separate them, and the error message carries uv's verbatim stderr, so the code is a coarse hint (telemetry, the extension recovery flow), not the sole diagnostic. Documented in `isUvResolutionConflict`. This pull request and its description were written by Isaac. --------- Co-authored-by: Isaac <no-reply@databricks.com>
deco-sdk-tagging Bot
added a commit
that referenced
this pull request
Sep 16, 2026
## Release v1.17.0 ### Notable Changes * Bump the direct deployment state version to 3. Clients older than v1.8.0 will reject bundles deployed with this release. ([#6713](#6713)) ### CLI * Add an `INVALID_REFRESH_TOKEN` error code to `databricks auth token --output json` failures. ([#6684](#6684)) * Add experimental `databricks auth docker configure` to configure Docker credential helper access for Databricks Artifact Registry. ([#6700](#6700)) * Add experimental `databricks auth docker token` to generate Docker credentials for Databricks Artifact Registry. ([#6699](#6699)) * `databricks environments setup-local` now reports the `E_PROVISION_CONFLICT` error code instead of the generic `E_PROVISION` when `uv sync` fails to resolve a dependency conflict. ([#6666](#6666)) * Preserve SSH sessions across temporary tunnel disconnects, with bounded replay and backpressure for large transfers. ([#6650](#6650)) * Allow OAuth U2M logins to override the CLI client ID with `--client-id`, profile `client_id`, or `DATABRICKS_CLIENT_ID`. ([#6594](#6594)) ### Bundles * direct: Store a dashboard's `serialized_dashboard` in state as a content hash instead of its full contents. ([#6105](#6105)) * direct: Fix pipelines recreation when the whole `ingestion_definition` block is added or removed. ([#6589](#6589)) * `bundle plan`, `deploy`, and `destroy` no longer report removing `permissions`, `grants`, or secret scope ACLs from a bundle as a deletion, since it leaves the resource untouched. ([#6647](#6647)) * `bundle plan` and `deploy` no longer list or count a resource that was already deleted remotely as a deletion, matching `bundle destroy`; applying still cleans up its stale state entry. ([#6675](#6675)) * Fix `bundle run` failing with `expected an int, found a string` when an unrelated resource references another resource that is not deployed. `bundle run` now resolves `${resources.*}` references only within the resource being run. ([#6690](#6690)) * Add grants support for the AI Gateway `model_service`, `mcp_service`, and `model_provider_service` resources (direct engine). ([#6635](#6635)) * Add bundle support for the AI Gateway `mcp_service` resource (direct engine). ([#6633](#6633)) * Add bundle support for the AI Gateway `model_provider_service` resource (direct engine). ([#6634](#6634)) * Add bundle support for the AI Gateway `model_service` resource (direct engine). ([#6525](#6525)) * Prevent resource drift on catalogs if `storage_root` contained a trailing slash in the URL. ([#6622](#6622)) * Fixed a "lineage mismatch in state files" error that could occur after destroying a bundle and redeploying it from another machine. `bundle destroy` now removes the local state file so no stale lineage is left behind, and prunes the state directories it leaves empty (such as `.internal/` and `sync-snapshots/`). ([#6210](#6210), [#6685](#6685)) * direct: `bundle plan` no longer reports a permanent update on a cluster that uses a cluster policy: when the cluster spec sets `policy_id`, a field present in the remote but absent from the bundle config is not treated as drift. ([#6531](#6531)) * `bundle deploy` on the direct engine now reports each resource as soon as it is deployed, instead of listing them all after the deployment finishes. A deploy that fails part way through now reports the resources it did apply. ([#6361](#6361)) * Direct-engine bundles no longer flag phantom drift on server-populated nested fields under reused config types (e.g. `external_locations` file-event-queue resource IDs, `database_instances` parent-instance refs, `apps` git credential ID). ([#6618](#6618)) * `databricks bundle generate app` now reproduces a git-backed app's `git_repository` and `git_source` configuration instead of emitting a workspace `source_code_path`, so generating from a Git-deployed app no longer silently converts it to workspace source. ([#6656](#6656)) * Improved configuration load time for bundles with many included files. ([#6195](#6195)) * `bundle destroy` no longer deletes triggered job runs, leaving them untouched on the backend. ([#6672](#6672)) * direct: resources.job\_runs: new lifecycle.triggers.on\_file\_change setting to restart the run when monitored files change. Can be set to a series of paths or globs. ([#6309](#6309)) * Bundle summary now shows a name for Postgres branches, endpoints, databases, and roles instead of a blank Name field. ([#6663](#6663)) * Added PyDABs (Python) support for cluster policies, dashboards, and Genie spaces. ([#6585](#6585)) * CLI commands no longer imply that a resource whose type has no workspace URL is merely not deployed yet. ([#6583](#6583)) * Capture the implicit dependency a vector search index has on a catalog or schema defined in the same bundle, so the catalog and schema are deployed first. ([#6655](#6655)) ### Dependency Updates * Bump dependencies with known vulnerabilities. ([#6695](#6695)) * Bump `github.com/databricks/databricks-sdk-go` from v0.177.0 to v0.178.0. ([#6673](#6673)) * Bump Terraform provider from v1.131.0 to v1.132.0. ([#6671](#6671))
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
3 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.
Why
environments setup-localreportedE_PROVISION_CONFLICTonly for direct-pin conflicts caught beforeuv syncby the merge phase (W_USER_CONSTRAINT_CONFLICT). A conflict in the transitive dependency graph is only discoverable by uv's resolver, so it faileduv syncwith a genericE_PROVISIONand got no conflict-specific handling — even though transitive conflicts are the more common shape.What
Classify a
uv syncfailure asE_PROVISION_CONFLICTwhen uv's stderr is its dependency-resolution failure (No solution found/unsatisfiable), so both conflict shapes carry the same code. Other sync failures (network, wheel build, interpreter) stayE_PROVISION. Layered on top of — not replacing — the pre-sync merge check.Testing
TestIsUvResolutionConflict,TestProvisionClassifiesResolutionConflict): resolver stderr →E_PROVISION_CONFLICT; unrelated stderr (incl. offline cache-miss) →E_PROVISION.acceptance/localenv/provision-conflict-sync): a fake uv failsuv sync; JSON output showsE_PROVISION_CONFLICTat the provision phase with noW_USER_CONSTRAINT_CONFLICTwarning — distinguishing it from the merge-phase path.GOOS.windows=false(same asacceptance/cmd/psql); the unit tests are cross-platform.Reviewer notes
Failed to fetch,Connection refused), so it staysE_PROVISION. The one reachability case that carries the resolver banner is an offline cache-miss (--offline/UV_OFFLINE), which also prints anetwork was disabledhint — explicitly excluded.No solution found … unsatisfiablebanner and are reported asE_PROVISION_CONFLICT. Accepted — both are user-actionable dependency problems, uv exposes no machine-readable signal to separate them, and the error message carries uv's verbatim stderr, so the code is a coarse hint (telemetry, the extension recovery flow), not the sole diagnostic. Documented inisUvResolutionConflict.This pull request and its description were written by Isaac.