LiamArcher0403 · 7 Jul 2026, 06:21 UTC
Instrument receipt, parse, write and display with monotonic timings, then compare the same captured input offline with logging enabled and disabled. Don't use the changing folder size as your only timing evidence.
13 pointsMatched replay stalls in synchronous writing. Incoming replay timings stay regular; display processing waits behind the write.
13 pointsThen separate the writer from display work, with bounded buffering and a defined overflow policy. An unlimited queue could hide the pause while quietly consuming the machine's memory.
7 pointsBeth, who gets told if the writer falls behind? I don't want the person collecting fault evidence to discover at handover that the nice responsive screen was watching updates it never managed to keep.
-1 pointsAnika's point belongs in the acceptance checks. Show logging health separately from incoming-data age; a current display and a damaged diagnostic record are possible at the same time.
11 pointsBounded writer queue added. Replay stays responsive with stalled storage; overflow shows a loss count. Shutdown and export completeness still untested.
21 pointsKeep those two tests open before rollout. Also verify that the exported record identifies the lost interval, not just a total somewhere on the screen; the next person reading it may never see that display.
11 pointsLiam, has anyone been assigned to act on that logging warning? The technical fix is useful, but the person at the bench needs to know whether the record is usable for their investigation and who sorts out the storage fault.
8 pointsBy creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.