DRAFT (do not merge): coherence F2 — invalidate facet counts at input, before the await

[rdhyee]

⚠️ DRAFT — do not merge. Codex has blocked this twice and I agree with it.

Opened as a draft so the work is visible and reviewable, not because it's ready.
Built overnight; two substantive blockers remain, detailed at the bottom.

What this is

The coherence audit's highest-value open item (F2), and the approach Codex argued for over a watchdog: "the invariant belongs at input invalidation, not at a timer attached to selected query paths."

The bug it targets

Both filter handlers had this shape:

writeQueryState(); refreshHeatmap();
await <globe reload>;          // long
refreshFacetCounts();          // only NOW are counts invalidated

That await is not short. Measured overnight on production: 168 s on 4G, 423 s on 3G — because the Explorer currently downloads ~74 MB on cold load (separate finding, #345). For that entire window the facet counts kept displaying the previous filter's numbers, unmarked.

#340 was this same shape with a different trigger. #341 and #342 fixed instances; this targets the class.

The change

invalidateFacetCountsNow() — synchronous, called before any await: bumps the request id, clears the pending debounce, and marks counts recomputing (which swaps text to (Loading…) after 400 ms via #342). It deliberately does not schedule a recompute. An inner try/finally guarantees a successor on success and on throw.

Demonstrated effect

400 kbps, toggle one source filter, sample the DOM every 0.4 s:

	production (no fix)	this branch
invalidated within 0.4 s	False	True
stale unmarked windows	27	0
what the user sees	(4,389,231) for 10+ s after deselecting SESAR	(Loading…)

Why it is NOT ready

1. Overlapping handlers can still fire a premature query. Change A invalidates and awaits; change B invalidates and starts newer work; A is superseded, settles first, and its finally schedules a recompute that can run while B's globe reload is still pending. facetCountsReqId prevents a stale repaint but not the premature query. Needs a dedicated filter-invalidation generation — not facetCountsReqId, which camera refreshes also mutate.

2. The verifier cannot prove what I claimed. It only ever lets the awaited work succeed, and the pre-fix code also repainted on success — so the run cannot distinguish the new finally from the old placement. It needs deterministic fault injection (force the query-state write to throw right after invalidation) and per-element rather than aggregate assertions.

3. Also outstanding: applySearchFilterChange() should get guaranteed-successor placement (not pre-await invalidation) — after clearing a search, a rejected reconcile can strand the old dash even though counts are computable again.

4. Untested risk: facet-tree.spec.js uses fixed 3 s sleeps then parses numeric text; if a globe reload exceeds 3 s it could now read (Loading…). I could not test this — the spec needs a docs/data mirror absent from this checkout. I confirmed it fails identically on a control build without this change (10/10 both), so this branch doesn't regress it, but the specific concern is unverified.

Verification that did pass

quarto render clean · tests/test_smoke.py PASS · tests/test_frontend_derived.py 40 passed · #341/#342 unaffected (search → 60/60 (—), 0 stuck; facet-only → real counts) · no page errors · deployed to fork staging.

Refs #340, #304, #305

🤖 Generated with Claude Code

https://claude.ai/code/session_01QCCDurpcLzMe7L72y2HDAa

[rdhyee]

🤖 rbotyee (Claude, operated by @rdhyee) — Raymond's intent: close out the project's stale open PRs. What I did: closing this one, on Raymond's approval, for the reasons below.

Closing rather than merging or rebasing. In your own words above: "Codex has blocked this twice and I agree with it" — and the two correctness gaps you documented (a race between overlapping filter handlers that can still fire a premature query; a verifier that can't actually distinguish this fix from the pre-fix code) are still unresolved. The problem this targets — facet counts going stale under a filter change — has a shipped, documented stopgap live in production (#341/#342: an honest (—) instead of a wrong number), so nothing regresses by closing this.

The diagnostics here (the invalidation-generation gap, the fault-injection testing gap) are good and worth keeping as a reference — this comment links back to them for whoever picks up #340's real fix next, rather than carrying a known-not-ready branch open indefinitely.

— isamples-0914 (Claude, for rdhyee)