Clicking through the sidebar quickly wastes 75-90ms per navigation on schema-column loading that is thrown away, and the tables in between never load.
Evidence
From a live trace on a Postgres connection over an SSH tunnel, clicking ten tables in a row at roughly 85ms intervals:
#4 beta_signups +24.7ms schemaColumnsBegin
#4 beta_signups +84.0ms ANOMALY supersededByNewNavigation replacedBy=#5 <- next click
#4 beta_signups +100.6ms schemaColumnsEnd <- still ran the full 76ms
#4 beta_signups +100.6ms END outcome=prepareAbandoned
Identical for #5, #6, #7, #8, #9, #10, #11, #12 and #13. Ten consecutive navigations each burned 75-90ms of schema loading and then discarded it. Only #14 survived to display anything.
Why it happens
loadSchemaColumns runs inside prepareTableTabFirstLoad (MainContentCoordinator+TableFirstLoad.swift), which sits before executeStarted. Two consequences:
The post-await guard then correctly discards the result, which is why the outcome is prepareAbandoned rather than a wrong-table bug. Nothing is incorrect here; it is purely wasted work.
Pre-existing
Not introduced by #2055. The trace added there is simply the first thing that made it measurable.
Suggested direction
Either extend the claim to cover preparation (mint at openTableTabQuery rather than executeQueryInternal, and check isCurrent before and after the await), or make loadSchemaColumns honour Task.isCancelled at its suspension points. The former also gives the preparation phase a timeline entry that the trace can attribute.
Clicking through the sidebar quickly wastes 75-90ms per navigation on schema-column loading that is thrown away, and the tables in between never load.
Evidence
From a live trace on a Postgres connection over an SSH tunnel, clicking ten tables in a row at roughly 85ms intervals:
Identical for #5, #6, #7, #8, #9, #10, #11, #12 and #13. Ten consecutive navigations each burned 75-90ms of schema loading and then discarded it. Only #14 survived to display anything.
Why it happens
loadSchemaColumnsruns insideprepareTableTabFirstLoad(MainContentCoordinator+TableFirstLoad.swift), which sits beforeexecuteStarted. Two consequences:executeQueryInternal, so work before that point has no owner to invalidate.cancelTableLoadcancels the wrapperTaskintableLoadTasks, but theawait loadSchemaColumns(...)inside it is not cancellation-aware, so it runs to completion regardless.The post-await guard then correctly discards the result, which is why the outcome is
prepareAbandonedrather than a wrong-table bug. Nothing is incorrect here; it is purely wasted work.Pre-existing
Not introduced by #2055. The trace added there is simply the first thing that made it measurable.
Suggested direction
Either extend the claim to cover preparation (mint at
openTableTabQueryrather thanexecuteQueryInternal, and checkisCurrentbefore and after the await), or makeloadSchemaColumnshonourTask.isCancelledat its suspension points. The former also gives the preparation phase a timeline entry that the trace can attribute.