Bundle deploy of an AI/BI dashboard breaks viewers' private bookmarks (UI save + publish does not)

Open
  • Is something wrong?
#7,419 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
backend-api-design, cli

Research direction

Start by tracing how databricks bundle deploy updates Lakeview dashboard drafts, then compare that path with databricks lakeview publish and the UI save behavior described here. The payload does not name source files or tests, so locate the dashboard update implementation and its coverage first. Done means an unchanged-content deploy preserves viewers’ private bookmarks, with a regression test covering the reported reproduction.

Written by the indexing model from the issue text.

Description

Describe the issue

Deploying an AI/BI dashboard with databricks bundle deploy breaks every viewer's private bookmarks on the published dashboard, even when the deployed content is identical to what's already there. After the deploy, each private bookmark that had saved filter values shows a warning icon: "N widgets are no longer available" (N = the dashboard's filter widgets, which keep the same widget names in the file).

A save + publish from the dashboard editor in the UI does not break them, and neither does calling only the publish step (databricks lakeview publish) on an unchanged draft. So it looks like updating the draft through the API (which the bundle deploy does before publishing) regenerates whatever internal widget identity private bookmarks refer to, while a UI save keeps it. The exported serialized_dashboard carries no extra identifiers we could preserve in the file: diffing the UI-saved draft against our file shows only the edit that was made.

This may sit in the Lakeview update API rather than the CLI, but bundles are where it bites: every CI deploy that touches a dashboard breaks all its viewers' private bookmarks.

Configuration
resources:
  dashboards:
    my_dashboard:
      display_name: My Dashboard
      file_path: ./my_dashboard.lvdash.json
      warehouse_id: ${var.warehouse_id}
      dataset_catalog: ${var.catalog}
      embed_credentials: false

Dashboard with ~11 filter widgets (single- and multi-select) on a global filters page.

Steps to reproduce the behavior
  1. databricks bundle deploy the dashboard.
  2. Open the published dashboard, change a filter value, and save a private bookmark.
  3. Run databricks lakeview publish <id> --warehouse-id <wh> (draft unchanged). Bookmark still works.
  4. Re-save the .lvdash.json with only whitespace changes (identical JSON content) and run databricks bundle deploy. The draft is updated and republished.
  5. Reload the published dashboard: the private bookmark shows the warning icon, "N widgets are no longer available".

For comparison: edit a widget title in the UI draft and publish from the UI. A private bookmark created beforehand keeps working.

Expected Behavior

Private bookmarks keep working after a bundle deploy when the filter widgets (same names) still exist, the same as after a UI save and publish.

Actual Behavior

All private bookmarks with saved filter values break after any bundle deploy that updates the dashboard, including a deploy with identical content.

OS and CLI version

Databricks CLI v0.298.0, macOS, Terraform deployment engine (default).

Is this a regression?

Unknown. Private bookmarks are new (October 2026 release notes).

Debug Logs

Can provide redacted logs if useful.

Dominant language
Go
Stars
427
Forks
267
Avg merge
2d 1h
Merged PRs (30d)
233

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from databricks/cli

All issues in databricks/cli

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.