Ruben FiszelandClaude Opus 5 6860521b4e refresh a dbt column trace with its graph, and stop calling whole ones cut (#11015) ...

* fix: refresh a dbt column trace with its graph, and stop calling whole ones cut

Follow-up to #11014, addressing two findings from the review round that landed
after it merged.

**A deliberate graph refresh now re-asks for the lineage.** The dedup key held
only the workspace, the pin and the seed relations, all of which a redeploy
leaves alone — so the pipeline page's Refresh refetched the graph and left the
trace as it was, pairing the new version's SQL and columns with the previous
one's edges. The key now carries which fetch of the graph is on screen, taken
from `graphRes.current`'s identity: it moves on a Refresh, a deploy and a folder
switch, and on nothing else, so an editor keystroke still cannot make the pane
re-ask.

**`truncated` is set only with evidence.** `pending` was read as proof the
component had been cut, but it only says a relation's owners have not been asked
about yet — and those owners are usually the project already in hand. A project
holding more than the expansion budget across unrelated families therefore
reported a small, complete component as truncated. The owners query now runs
before the budget and round stops, so a trace is called cut only when a project
this caller may read is left unread, or when the walk itself was cut.

Two smaller things from the same round: a failed lineage request says so instead
of rendering the empty trace a project without the analysis pass renders — the
two were indistinguishable, and a Refresh now retries it — and `asset_paths` is
capped as well as refused when empty. `MAX_HELD_EDGES` is renamed
`EXPANSION_EDGE_BUDGET`: it never bounded what its name claimed, since the seeds'
own projects are read whole whatever their size.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NY4kuFy2jAnGEzaCc1CseL

* fix: show a failed column-lineage request beside a partial trace, not only instead of one

Review-round findings on this PR.

The failure line only rendered when the trace had no nodes at all. A ducklake
selection whose producers declare column lineage has nodes from the graph the
canvas already carries, so a failed dbt request left a trace that rendered and
was missing a half — which is the reading the line exists to prevent. It now
renders beside a drawn trace as well, and says the trace may be incomplete
rather than that nothing loaded.

The dbt branch of the details pane also opened on `selectionColumnLoading` but
not on the failed state, so a relation with neither SQL nor a column schema fell
through to "no inline preview" and the line never rendered at all.

Dropped "Refresh to try again": the dbt editor has no Refresh for this, and its
recovery is a re-parse or reselecting. The comment on the error handler says both
paths again rather than only the one the pipeline page uses.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NY4kuFy2jAnGEzaCc1CseL

* fix: clear a column-lineage failure when the next request goes out

Round-2 nits, both reviewers on the same state.

`failed` was cleared only when an answer landed, so a retry kept saying the trace
may be incomplete while it was being fetched, and a new selection inherited the
previous one's failure until its own answer arrived. It is cleared as the request
goes out instead.

Also documents the bounds on `asset_path` in the two routes that take it: the
1000-relation cap and the at-least-one rule were both enforced and neither was
written down, so a caller met them as a 400 with no way to have known.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NY4kuFy2jAnGEzaCc1CseL

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-08 11:41:05 +02:00

1.0 MiB

Raw Blame History