[ergofobe]

Closes #89. Closes #94.

The two defects in the Repairs panel, one on each side of the wire.

The web half — #89

The mechanism the issue describes is the one that was there. refetchInterval read data to
decide whether to keep asking; after a failed poll data is undefined, so it returned false,
and with retry: false nothing ever asked again. The render path then folded isError in with
"nothing to show" and returned null. One transient 500 took the Repairs controls off the page
for the life of the tab, with no error and no way back, while a pass might still have been
walking the library.

It now gets the treatment the queue panel directly above it already had — the failure reported
with its reason and a Try again button, and an interval that keeps asking — with three
corrections the review turned up:

• The banner sits over the list, not instead of it. React Query keeps the last good answer
  through an error, and this only polls while a pass is walking, so replacing the list would have
  blanked the running row and the Start buttons on every blip in the fifteen-second cadence.
• A 404 gets no exemption. It reads like "this server is too old to have the route", which is
  exactly the wrong inference here: the admin API refuses everything with a plain 404 on purpose,
  being meant to be undiscoverable rather than merely closed. An expired session arrives as the
  same status, and excusing it left a stale list with "Walking the library" still showing and
  nothing asking again — One failed poll hides the Repairs section with no error and no retry #89 by another road. Nothing is lost, because the bundle is served by the
  server it talks to.
• <Repairs> stays mounted when the queue fails. It was rendered only inside the queue
  query's success branch, so one failed GET /api/v1/admin/queue unmounted it — and a banner
  cannot report anything from a component that is not there.

repairsPollInterval is exported because that function is the defect, and a rendering assertion
cannot see the half of #89 that is "never asks again".

The server half — #94

repairs() selected every queued and running job row to build a Set of two names, and the panel
polls it every fifteen seconds while a pass walks — exactly when a bulk import has tens of
thousands of rows queued. It is now bounded by the two names and grouped, the shape queueHealth
a few lines above already uses.

Measured on a jobs-shaped table of 120,000 rows with only the existing jobs_claim_idx:

	rows returned	time
before	60,001	12.8 ms
after	1	6.4 ms
with an index on (name, status)	1	0.025 ms

So this removes the part that was actually costly — 60,000 rows crossing the wire and being
materialised into JavaScript objects — and leaves the scan, which is a separate trade-off about
indexing a write-hot table. See Found, not fixed.

Tests

Written first, each watched to fail:

• admin.test.ts — "asks about the two repair jobs rather than reading every queued row". Drives
  repairs() through a drizzle instance with a query logger and asserts the SQL's parameters carry
  both repair job names, alongside the answer still being right with 200 unrelated rows queued. A
  right answer bought by dragging the whole queue into memory is the defect, and no assertion about
  state can see it.
• adminProcessing.dom.test.tsx — five: the section says so rather than vanishing; it offers a way
  to ask again and comes back; the interval keeps asking after a failure; a 404 is reported like any
  other failure; the list survives both a later failed poll and a failed poll of the queue above it.

The file's stubs now reset in an afterEach rather than on each test's last line — the line that
does not run when an assertion above it throws.

Verify

bun install && bun run verify && bun run --filter '@imogen/web' build — green. 970 pass, 0 fail.
No bun.lock diff; the SDK pin is untouched at v0.5.1.

Not clean — three review iterations spent

Per CLAUDE.md this is left open rather than self-merged. code-review at medium was run four
times and fixed after three; the fourth run is not clean. Outstanding:

• significant — AdminProcessing.tsx, the remount. <Repairs> sits at child index 1 in the
  queue-error branch and index 2 in the success branch, so React reconciles positionally and
  unmounts and remounts it on every queue error↔success transition. An intermittently failing queue
  polls every three seconds, and each flip discards the start mutation's error message and
  triggers a fresh repairs refetch — two whole-table counts over assets, one on a JSON field no
  index serves, which is the load The Repairs panel reads every queued job row, every fifteen seconds, to check two names #94 was tightening. The suggested fix is to hoist the conditional
  queue section into one stable slot so Repairs never changes position. It needs a test of its
  own, which is what the budget ran out before writing.
• nit — the error banner's disabled={isFetching}. While the query is polling in its error
  state the button spends most of its time as a disabled "Asking", for a request that may take the
  full 45s backstop. Noted rather than fixed because it is a pattern: the queue panel's button
  above is the same code, and changing one would put them out of step.
• nit, pre-existing — the queue branch is if (isError || !data), so a failed queue poll
  replaces the whole panel even though the last good data is still held. Arguably deliberate
  (A wedged database pool stops every background job silently, and the admin Processing screen shows a skeleton for ever #71's "a skeleton here would be a lie"), which is why no issue was filed, but it is the thing
  that makes the remount above possible.

Found, not fixed

• The jobs table has no index on name, so the Repairs poll still sequentially scans it #114 — jobs has no index on name, so the poll still sequentially scans
  it. Indexing a write-hot table to save a read made four times a minute is its own trade-off.

🤖 Generated with Claude Code