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.
- A throbber (#ram-batch-spin) next to the phase line shows while a card
is actually being installed (active && current - the stopping-mid-
install phase included) and hides again while waiting.
- The waiting prompt is explicit now: "Insert next card. Waiting for a
card..." (RU "Вставьте следующую карту. Ожидание карты…"); the old
"Waiting for a card..." key is gone.
- The notice reports only the last *finished* card: starting the next
card's install clears it (state['notice'] = '' alongside
current/installing in _ram_batch_handle_card), so the previous card's
verdict never lingers over the next install. It stays visible while
waiting - the "report the status + ask for the next card" behavior.
- The batch operation's RU label is "Пакетная установка (.cap на
множество карт)"; the help row's title aligned.
Tests: the render test (the new prompt, the throbber visible while
installing / stopping-mid-install and hidden while waiting, an empty
notice hiding the box) and the worker test (the notice is empty
mid-install and set again for the new outcome). 915 frontend + 925
Python; sw cache simple-v439.
- A non-ValueError exception from the install run (a card removed
mid-chain, a transport error) was recorded as a 'skipped' attempt with
the error text - but the chain had started and died, which is a
failure. Only a ValueError (a request/eligibility error: the preset's
ISD keyset, the plan) is a skip now; anything else is a 'failed' record
carrying its error. The PWA's failed row falls back to that error when
there is no failing step / status word to show.
- The panel's Clear button is disabled while a batch is active (the
server refuses the clear with 409 anyway) - no pointless error alert.
- api.md and the repo AGENTS document the two outcomes. Tests: a
transport error mid-chain is a failure (and the card stays seen), the
plan's input validation (the block size, a missing cap_hex), the failed
row without a step, the shared ram_format field, and the Clear state.
915 frontend + 921 Python; sw cache simple-v438 (unchanged).
The bulk workflow: one .cap and one set of install parameters applied to
card after card - swap cards and each one installs as soon as it is
equipped. The server owns the loop, so closing the tab or reloading the
page does not interrupt it.
The install chain is now shared: _ram_install_plan(body) builds the
card-independent part (the parsed .cap, the INSTALL/LOAD sequence, the
block size, the transport knobs) and _ram_install_run(server, body, plan,
scc) runs one chain (the per-card preset/keyset/counter resolution
included); the /api/ram-install handler is the plan + run + response, and
the batch worker calls the same pair. The plan is built once at Start,
so a bad .cap or parameter combination is a 400 there (a malformed
archive included - a zip parse error is the caller's, never a dropped
connection), not a per-card failure. _op_keyset_resolve() is the module
form of the handler's _op_keyset() (the dead _keyset_guard method is
gone).
The worker (_ram_batch_worker, state _RAM_BATCH) polls the card state
every 0.5 s and acts on a new card session while connected; a card
already equipped at Start installs immediately. Per card the preset is
matched by ICCID and its ISD role TAR supplies the keyset (v3.26.0) and
the counter seed (v3.20.0); a card with no readable ICCID, no matching
preset or no usable ISD keyset is recorded as skipped with its reason.
A card is attempted once per run (any outcome): re-equipping it records
"already processed in this batch (<outcome>)" and never installs again -
restarting the batch is the retry. Failures carry the failing step and
the remote SW, are never retried and never stop the run; an unexpected
card-handling error is recorded and the loop keeps waiting.
Endpoints: POST /api/ram-batch/start (no card needed; 400/409), GET
/api/ram-batch/status (card-free - the panel polls it during an install),
POST /api/ram-batch/stop (the first _CARD_FREE_POST: it only sets a flag,
so the button works while the worker holds the card lock; a running
install always finishes first) and POST /api/ram-batch/clear (409 while
active). /api/status carries the ram_batch summary (the detailed state
minus the attempts list), so the panel's headline - the live phase, the
current card, the counts - rides the 2 s poll; the attempts report (the
last 500 kept, the total counted) is fetched only when it changed. The
batch and a test run exclude each other (409 both ways); the state is in
memory - a server restart ends a run.
PWA: the Batch install (.cap file, per card) RAM operation shares the
install form (ramInstallCapFields(); the single install uses it too and
now sends ram_format, and the block-size validation moved before the
modal), hides the preset selector + Execute and the preset-mismatch
banner, and renders Start/Stop/Clear, the phase headline (equip the next
card / installing card + live step / stopping after the current card),
the counts and the attempts table (newest first). The panel only works
inside the visible SCP80 RAM pill.
Docs: help EN/RU, api.md (a section + the four table rows), the repo
AGENTS. Tests: the state/report helpers, the per-card decisions, the
worker loop (a real thread + a fake install), the lifecycle and guards,
the HTTP endpoints (the malformed .cap, the stop under a held card lock,
the test-run refusal) and the PWA panel helpers/wiring. 914 frontend +
919 Python; sw cache simple-v438.
catarrh