Problem
We attribute main-thread long tasks to the sync stage that caused them using performance.mark pairs around our own collection commits (co:sync:commit:start/end). The other half of the picture, the time a commit spends re-running dependent live queries, has no public seam: CollectionConfigBuilder.executeGraphRun / maybeRunGraph run synchronously inside the source collection's commit and are private, and CollectionConfigBuilder is not re-exported from @tanstack/db.
What exists publicly today does not cover it:
createLiveQueryObserver subscribes to changes and status, not to the run itself.
createEffect's per-graph-run callback fires per effect query, so instrumenting it does not cover useLiveQuery / createLiveQueryCollection sites (we have ~65).
- Collection events are
status:change, subscribers:change, index:added, index:removed.
Patching the dist to wrap executeGraphRun works but is a vendor carry we do not want to maintain for a metric.
Request
A public, opt-in event around a live query's graph run, for example on the live query collection:
collection.on('graph:run', ({ id, durationMs, changes }) => { /* mark / measure */ })
or a global hook (onLiveQueryRun(listener)) that fires with { id, startTime, endTime } per executeGraphRun. Either lets consumers emit performance.mark pairs with detail: { collection: id } and lets DevTools-style tooling attribute long tasks to specific queries without touching internals.
Context
@tanstack/db 0.7.2. Related to the offset-regression issue we filed against electric-sql/electric#4806 in the same instrumentation effort.
Problem
We attribute main-thread long tasks to the sync stage that caused them using
performance.markpairs around our own collection commits (co:sync:commit:start/end). The other half of the picture, the time a commit spends re-running dependent live queries, has no public seam:CollectionConfigBuilder.executeGraphRun/maybeRunGraphrun synchronously inside the source collection's commit and are private, andCollectionConfigBuilderis not re-exported from@tanstack/db.What exists publicly today does not cover it:
createLiveQueryObserversubscribes to changes and status, not to the run itself.createEffect's per-graph-run callback fires per effect query, so instrumenting it does not coveruseLiveQuery/createLiveQueryCollectionsites (we have ~65).status:change,subscribers:change,index:added,index:removed.Patching the dist to wrap
executeGraphRunworks but is a vendor carry we do not want to maintain for a metric.Request
A public, opt-in event around a live query's graph run, for example on the live query collection:
or a global hook (
onLiveQueryRun(listener)) that fires with{ id, startTime, endTime }perexecuteGraphRun. Either lets consumers emitperformance.markpairs withdetail: { collection: id }and lets DevTools-style tooling attribute long tasks to specific queries without touching internals.Context
@tanstack/db0.7.2. Related to the offset-regression issue we filed against electric-sql/electric#4806 in the same instrumentation effort.