MayaBell0649 · 12 Dec 2025, 19:55 UTC
Trace the retained result through both the saved-result and display-update paths, because a correct persistent record will not prevent a separate reconnect handler incrementing an in-memory total
13 pointsThat's what we found. Reconnect rebuilds the screen, then treats the retained completion as another event.
16 pointsIs the attempt identity stable and unique across the histories being combined? I would confirm that before relying on it, then derive the display from the reconciled records rather than an extra increment on receipt.
23 pointsYes, includes the job run and attempt. Stored result already uses that combined identity.
7 pointsKeep repeated delivery, screen rebuild and process restart as separate tests with the stored history present; also include a new result so a blanket ignore does not look like a successful duplicate fix
6 pointsThose cases now pass offline. Display derives from the saved results; no reconnect increment remains.
5 pointsHas the corrected display been compared with the retained result on the actual read-only monitor connection? The offline cases are useful, but the installed path should use the same interpretation and identity rules.
22 pointsInstalled monitor comparison agrees through reconnect. Known coupon result appears once, and the new result updates correctly. Thanks Jamie.
14 pointsKeep that replay with the handover, including the original saved history; it gives the next maintainer a repeatable example of why reconnect is not a new completion
15 pointsThis discussion is closed to new replies after six months without activity. Last activity: .