jerry/buzz

mirror of https://github.com/block/buzz.git synced 2026-10-30 14:01:37 +00:00

Files

Max Lampert f0517728e9 fix(desktop): don't cancel the fetch the timeline is waiting on

Converging review found this at P1, two lenses independently, both with
probes against the installed query-core source. Reproduced here.

The prefetch marker records that a channel had a prefetch requested, not
which fetch is in flight. On a cold channel `prefetchQuery` does not start a
fetch at all — TanStack dedupes onto the request already running (query.js
honours `cancelRefetch` only when `state.data !== undefined`). So when the
hover dwell fires after the click, which is the ordinary case for a decisive
click inside the 100ms dwell, the marker labels the mounted timeline's own
fetch a "prefetch", and the post-subscribe refresh cancelled it.

Probe, real modules and a real QueryObserver:
  no hover:           { calls: 1, mountFetchAborted: false }
  hover then click:   { calls: 2, mountFetchAborted: true }

That is two sequential relay round trips with the skeleton held across both,
making a hovered channel slower to open than an unhovered one — on the exact
path this stack exists to speed up.

The refresh now waits for the in-flight fetch instead of cancelling it. The
gap it was closing still closes: the invalidate below re-reads the window
after the subscription exists, it just no longer discards the round trip the
user is watching. #6455's one-fetch contract for a cold channel with no
prefetch is unchanged.

The guard's own comment claimed a cold mount fetch "is still parked on the
hydration gate" and so could not be affected. That is false in steady state —
`channelHeadHydration` is an already-resolved promise after boot.

Adds the regression test; it fails on the cancelling version.

Signed-off-by: Max Lampert <maxwell@squareup.com>

2026-08-27 17:49:10 -07:00