Found by PR #628's own mutation table (#511 round 3, row M14), and confirmed independently by the driver.
What was measured
web/src/routes/InventoryPage.tsx, in loadLots:
const req = ++lotsRequest.current;
const lotRows = await listInventoryLots(itemId);
if (lotsRequest.current !== req) return; // <-- this line
Replace that condition with if (false) return; — disabling the stale-response rejection entirely — and:
InventoryPage.test.tsx: 54 / 54 pass- the whole SPA suite: 88 files / 2026 tests, all pass
Nothing anywhere notices. The guard has no test.
Why it is worth an issue rather than a fix in #628
The mechanism is structurally sound — lotsRequest only ever increments, so an older response can never satisfy lotsRequest.current === req once a newer call has started. That soundness rests on reading the code, not on a red/green proof, which is precisely the failure mode #511's own review round kept hitting one level up: a guard nobody tests reads as safety.
It is also not a defect #511 introduced. Pre-#511 the same pattern guarded the combined movements+lots read as ledgerRequest; #511 split that into the paged ledger (whose ticket lives inside usePagedList and IS tested there) and lotsRequest. The untested-ness came along with the split rather than being created by it.
The owner's call on 2026-08-31 was to file this rather than spend another round on it, on the grounds that it is a control for a control.
The test that would close it
Open item A with its lots read left pending; open item B and let B's lots resolve; then release A's late response. Assert B's lots are still the ones rendered. That interleaving — an older response landing after a newer one — is the one thing the ticket exists for, and no test in the file drives it. Note that #628's round-3 test deliberately covers a different window (what is on screen while B's lots are in flight), so the two are complementary, not duplicates.
Related: #511, PR #628, #629, #630.
Found by PR #628's own mutation table (#511 round 3, row M14), and confirmed independently by the driver.
What was measured
web/src/routes/InventoryPage.tsx, inloadLots:Replace that condition with
if (false) return;— disabling the stale-response rejection entirely — and:InventoryPage.test.tsx: 54 / 54 passNothing anywhere notices. The guard has no test.
Why it is worth an issue rather than a fix in #628
The mechanism is structurally sound —
lotsRequestonly ever increments, so an older response can never satisfylotsRequest.current === reqonce a newer call has started. That soundness rests on reading the code, not on a red/green proof, which is precisely the failure mode #511's own review round kept hitting one level up: a guard nobody tests reads as safety.It is also not a defect #511 introduced. Pre-#511 the same pattern guarded the combined movements+lots read as
ledgerRequest; #511 split that into the paged ledger (whose ticket lives insideusePagedListand IS tested there) andlotsRequest. The untested-ness came along with the split rather than being created by it.The owner's call on 2026-08-31 was to file this rather than spend another round on it, on the grounds that it is a control for a control.
The test that would close it
Open item A with its lots read left pending; open item B and let B's lots resolve; then release A's late response. Assert B's lots are still the ones rendered. That interleaving — an older response landing after a newer one — is the one thing the ticket exists for, and no test in the file drives it. Note that #628's round-3 test deliberately covers a different window (what is on screen while B's lots are in flight), so the two are complementary, not duplicates.
Related: #511, PR #628, #629, #630.