[helgehoi]

Ticket

VI-5068 — [tamstool] Upgrade TAMS Store Browser to TAMS 8.2

Third go at this; #23 and #24 each fixed a real defect but not the one that bites. This one is reproduced, not deduced.

The bug

With /#/embed open against an 8.2 store, a recording that starts never grows an Open button and never lights up as LIVE. A reload produces both at once.

Reproduction

A stub TAMS 8.2 store driven through the real app in headless Chrome, starting a recording while the page sits open:

ON main (96ba867)                        WITH THIS CHANGE
before:  open:false live:false           before:  open:false live:false
t+25.0s: open:false live:false           t+25.0s: open:true  live:true
t+30.0s: open:false live:false           t+30.0s: open:true  live:true
RESULT: never appeared, no reload        RESULT: appeared 5s in, no reload
after reload: open:true                  after reload: open:true

Worth recording what it took to reproduce: a plain source and a multi-source both passed on main. The failure needs a store whose ingesting listing does not change when the recording starts — with that, the symptom is exact, including the reload asymmetry.

Why

The re-check was keyed on the sources listing:

}, [api, displayedSources, liveSourceIds, canQueryCollections, resolved]);

and that listing is deliberately built never to change. paginationFetcher:

// segments_updated changes on every ingested segment. Dropping it from list
// responses keeps SWR from re-rendering the whole table every poll
const items = records.map(({ segments_updated, ...remainder }) => remainder);

SWR then keeps the previous reference when the new data is deeply equal:

compare(cacheData, newData) ? cacheData : newData    // swr/dist/index

So while an ingest is under way — exactly when a source has something new to say — the listing is unchanged, the array reference is unchanged, and the effect does not fire. #24 rested on "the 5s sources poll re-examines them"; that poll re-renders nothing. The re-check now runs on its own setInterval, independent of the listings.

LIVE failed for a related reason: isGrowing was judged on the listing record — the one with segments_updated stripped — so isFlowGrowing fell back to created, and a flow created more than ten minutes before its ingest read as an abandoned one. It is now judged on the flow detail, which is already fetched for the timerange and does carry segments_updated. That is the live:false → live:true in the table above.

Also included

#/embed?debug traces what each source resolved to — flow id, status, timerange, isGrowing, hasSegments, settled. The stores this affects can only be reached from the deployed origin (they whitelist the tamstool origin, not localhost), so a reload-free way to see the decision from a browser console is worth the six lines.

Testing

• Reproduced on main and confirmed fixed here, via the stub store + headless Chrome run above
• npm run build passes (Node 22, same as CI)
• npm run lint still cannot run in this repo (ESLint 9 needs a flat config, deliberately left out of VI-5068 Support TAMS 8.2 in the TAMS Store Browser #20) — the build is the gate

Not yet confirmed against the real 8.2 store: it whitelists the deployed origin, so this has to ship before it can be tested there. The stub reproduces the reported symptom exactly, but whether the real store's trigger gap is the same one is what the deploy will settle.

🤖 Generated with Claude Code