Greetings @amrim , this is a well-scoped report, and your isolation table does most of the diagnostic work for us.
Thanks for laying it out that way.
The behavior you documented is consistent, and it points at the product, not your notebook or cluster. Same dashboard, three export paths, and only the job-run UI button fails while interactive export and the Jobs API export both work. That rules out the dashboard content, the runtime, and the cluster, so the DBR 16.4.27 and cluster details, while good to include, are almost certainly not the cause here.
The error you hit, {"error_code":"INVALID_PARAMETER_VALUE","message":"Path (???) doesn't start with '/'"}, is the path validator rejecting an invalid or empty value: it expected an absolute workspace path and got something that is not one. This matches a UI-side regression that has been reproduced internally, affecting notebook dashboards viewed from a job run. The Jobs API path avoids the problem because runs/export takes the run_id directly and never has to resolve a workspace path, which is why that route keeps working.
Two workarounds while the fix is pending:
- Export via the Jobs API instead of the job-run UI. This is the reliable route, and the one to use if you need this run's exact output:
- Endpoint:
POST /api/2.2/jobs/runs/export
- Parameters:
run_id for the run, and views_to_export=DASHBOARDS (use ALL if you also want the notebook code)
- Response: one HTML string per dashboard in the
views array
- Caveat: this endpoint only exports notebook task runs, so it fits your case but will not cover non-notebook task types.
- Open the notebook and its dashboard in interactive mode and export from there, which you already confirmed works. One thing to keep in mind: interactive export re-renders with current data, so it will not reproduce the exact snapshot from that specific job run. Use this only when a fresh render is acceptable.
If you have not already, I'd file this with Databricks support and include your workspace, the run_id, and a rough timestamp so they can tie it to the request logs, then reference this thread. That gives whoever picks it up a clean starting point.
Until the fix ships, the API export is your dependable path, and it is the better option for anything you want to automate anyway.
Regards,
Louis