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

Offen
  • Stimmt etwas nicht?
#7,419 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
go
Bereich
backend-api-design, cli

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Go
Sterne
427
Forks
267
Ø Merge
2 T. 1 Std.
Gemergte PRs (30 T.)
233

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus databricks/cli

Alle Issues in databricks/cli

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.