`bundle deploy` cannot update an app on v1.14.0 — `deployment_source.source_code_path cannot be set on UpdateApp` (regression from v1.13.0)

[geoffyip]

CLI version: v1.14.0 (latest, released 2026-08-26). Works on v1.13.0.
Engine: direct (bundle.engine: direct)
Cloud: Azure Databricks

Summary

On v1.14.0, any bundle deploy that updates an existing Databricks App fails immediately with a 400. The CLI includes source_code_path as an empty string in the UpdateApp request body, and the API rejects that field on update at any value.

The field is not in the request's own update_mask, so the CLI is not asking to change it — it is simply present in the body when it must be absent.

Reproduce

Precondition that may matter: the app must already have an active deployment. PR #5943 excludes the deploy-only fields "whenever the app has no active deployment", so an app that has never started may not reproduce this.

1. Declare an app in a bundle on the direct engine:

bundle:
  engine: direct

resources:
  apps:
    my_app:
      name: "my-app"
      source_code_path: ../app
      compute_size: MEDIUM
      resources:
        - name: "sql-warehouse"
          sql_warehouse:
            id: "<warehouse-id>"
            permission: "CAN_USE"

2. databricks bundle deploy -t dev once, and databricks bundle run my_app -t dev, so the app has an active deployment.
3. Change anything about the app resource — in our case, adding uc_securable entries.
4. databricks bundle validate -t dev → OK. databricks bundle plan -t dev → reports update apps.my_app normally, with no hint of a problem.
5. databricks bundle deploy -t dev

Expected: the app updates.

Note that only deploy fails. validate and plan are both clean, which localises this to the update payload rather than to config or drift detection.

Actual:

Error: cannot update resources.apps.<app>: updating id=<app>:
deployment_source.source_code_path cannot be set on UpdateApp. (400 INVALID_PARAMETER_VALUE)

Endpoint: POST https://<host>/api/2.0/apps/<app>/update
HTTP Status: 400 Bad Request
API error_code: INVALID_PARAMETER_VALUE
API message: deployment_source.source_code_path cannot be set on UpdateApp.

The request

Captured with --debug and DATABRICKS_DEBUG_TRUNCATE_BYTES=20000 (the default truncation hides the relevant tail):

POST /api/2.0/apps/<app>/update
{
  "app": {
    "compute_size": "MEDIUM",
    "description": "...",
    "name": "<app>",
    "resources": [ ... ],
    "source_code_path": ""
  },
  "update_mask": "description,budget_policy_id,usage_policy_id,resources,user_api_scopes,forward_user_access_token,compute_size,compute_min_instances,compute_max_instances,git_repository,telemetry_export_destinations"
}

Note "source_code_path": "" in the body, and its absence from update_mask.

It is a regression, established by rollback

Same bundle, same config, same target, same workspace — only the client changed:

CLI	POST /api/2.0/apps/<app>/update
v1.13.0	200, proceeds to the async update
v1.14.0	400 INVALID_PARAMETER_VALUE

Re-installing v1.14.0 reproduced the 400 immediately, so this is client-side.

Why this looks like a known family

The CLI already treats source_code_path as deploy-only:

• PR #5042 — "Deploy-only fields (source_code_path, config, git_source, lifecycle)" excluded from the Apps update mask.
• PR #5943 — "these fields are excluded from the App Update call and only deploy on start", but scoped to apps with no active deployment. The app here has an active deployment, which may be the uncovered path.

Impact

Every bundle deploy we attempted against this app on v1.14.0 failed this way — three attempts across two config shapes, with and without compute_size declared. That is one app on one workspace, so we cannot say from here that it is universal, but the field is added during payload construction rather than from anything app-specific, so we would expect it to affect any app with an active deployment.

Workaround: roll the CLI back to v1.13.0 for the deploy and roll forward afterwards.

Aside — the API docs disagree with the service

apps/update lists source_code_path as a settable Beta request-body field and documents no deployment_source wrapper. The running service rejects it and names a deployment_source. prefix. Whichever is intended, the doc and the service currently disagree.