dbt lineage browsing stalls when every focus change recompiles

The Lineage panel should help a developer move quickly through a model graph. A dbt issue reports that changing focus repeatedly triggered Parse and full background compilation even with no file changes. In the reporter's small test project, each compile took several seconds; faster navigation caused cancellations and another full compile. This is a reported extension behavior, not a universal performance benchmark.

Prove where the time goes

Record dbt extension and engine versions, project size, static-analysis mode, and the exact navigation sequence. In the dbt LSP output, compare the timestamp of each focus change with Parse, “No files changed,” cancellation, and full compile messages. If one deliberate focus change after an idle period is fast but rapid focus changes are slow, the bottleneck may be repeated compilation rather than graph rendering. Keep the trace short enough to send to the extension team.

Protect the analyst's work loop

While investigating, avoid using the Lineage panel as a rapid browser for a large DAG if it repeatedly recompiles. Open the relevant model files directly or use a generated lineage artifact for broader review. Do not disable validation across the project just to make one panel feel responsive. Compare the same project on the same extension version with a controlled action sequence.

Define an acceptance test for the fix

The dbt extension documentation says the panel follows the open file and supports double-click navigation. The LSP feature guide lists incremental and lazy compilation. A useful regression test is therefore: compile once, switch focus through several unchanged nodes, and confirm that no full project compile is launched for each read-only navigation. Re-run the test after extension updates before telling teams the issue is resolved.

Adovo’s view

A developer tool earns trust by keeping observation cheap. When looking at lineage starts work as heavy as building it, people stop checking lineage. Measure the hidden compile cost, then set the fix criterion around the actual browsing task.