ramBatchFetch's re-entrancy guard (_ramBatchFetching) is only cleared
when the fetch settles, and ramBatchApplyStatus returned without
rendering whenever it decided a fetch was due - so one stalled
/api/ram-batch/status request (the browser's fetch has no timeout) froze
the whole panel (counts, phase, notice, throbber) at the last successful
render while the server kept installing (live 2026-10-14: 31 installs,
the panel stuck at "Installed: 12"; the log showed all 31 attempts and a
healthy /api/status cadence, so the data was there).
- The summary render now runs on every poll before the fetch decision:
the headline (phase, current card, counts, notice) always follows the
2 s /api/status poll; the detailed fetch only adds the attempts table.
- A fetch guard older than RAM_BATCH_FETCH_STALE_MS (10 s) is released,
so a stalled fetch cannot block the report forever - the next poll
retries and the attempts table recovers.
Reproduced with the page's real functions: 12 good fetches, the 13th hung
-> the panel stuck at 12 (the reported number); with the fix it follows
the summary to 31 and the stale guard retries. Tests: a hung fetch keeps
the counts following the summary; a stale guard is released and retried
(a fresh one is kept). 919 frontend + 928 Python; sw cache simple-v445.
catarrh
269e507580