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

Abierto
  • ¿Algo no está bien?
#7,419 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
backend-api-design, cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
427
Forks
267
Merge medio
2 d 1 h
PR fusionados (30 d)
233

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de databricks/cli

Todos los issues de databricks/cli

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.