F7: the round-2 isError safety-net released the stopping latch too broadly. In
TanStack Query v5 (retry:false) the query's data is RETAINED on error, so
runQueryFailed can be true while `run` is still an ACTIVE held run — a single
transient GET-run failure between Stop and settle released the latch early and
re-opened the observer merge, flashing the growing detached run over the frozen row
(exactly the F4 flash the safety-net was meant not to reintroduce). Extract the
decision into a pure shouldClearLatchOnQueryError helper gated on !isRunActive(run)
(so it only ever cures the permanent-null-freeze, never releases against an active
run) and call it from the effect with `run` in deps. Document the latent invariant
that the null-branch clear is safe only because refetchInterval stops polling on
empty data.
F8: unit-test the real helper (not a mirror) — an active run + transient error does
NOT clear the latch (catches F7, non-vacuous against the pre-fix condition); null /
terminal run clears. The stale-terminal-run guarantee stays covered by
shouldClearStoppingLatch's tests.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
agent_coder
fb2460802d