The FR5 completion survives reconnect and gets counted again

SaraAbbott0026 · 19 Feb 2026, 05:31 UTC

Closed
SA
SaraAbbott0026
We have agreed who owns the ordinary job signals. This monitor still counts a retained completion again after reconnect. It needs to identify the existing job before updating our plate total.

16 replies

EM
EmmaChan1072
Replying to SaraAbbott0026

Does the saved history already contain that job's completion, or is the monitor only carrying forward a total?

14points
SA
SaraAbbott0026
Replying to EmmaChan1072

Saved history contains it with the job identity. The connection handler creates an empty list of seen completions on every reconnect.

18points
TH
TheoAbbott0062
Replying to SaraAbbott0026

Reconcile against the durable history rather than the connection's temporary list. Reconnection is a transport event; it need not create a new inspection or erase knowledge of a completed one.

12points
YA
YasminAli0180
Replying to SaraAbbott0026

What does the operator see while that reconciliation happens, Sara? I wouldn't leave a fresh-looking total on screen if the application is still deciding what it has already counted.

-3points
NO
NoraBell0670
Replying to YasminAli0180

And does anyone have to press continue? That word can mean almost anything after an interruption.

17points
SA
SaraAbbott0026
Replying to YasminAli0180

It currently shows connected and the old total immediately. No operator button. Developer is adding a reconciling indication before the current total is presented.

6points
EM
EmmaChan1072
Replying to SaraAbbott0026

What happens if the retained completion has an identity absent from the saved history? It could be work completed while the monitor was away.

21points
TH
TheoAbbott0062
Replying to EmmaChan1072

That case needs a defined reconciliation rule. Absence from the local completed set is not enough to treat an arbitrary retained state as a new authorised result. Compare it with the persisted pending job too.

4points
YA
YasminAli0180
Replying to TheoAbbott0062

Theo, would you show that unknown case separately from the duplicate one? For a covering operator, one is already accounted for and the other needs somebody to decide what happened.

13points
TH
TheoAbbott0062
Replying to YasminAli0180

Yes. A known duplicate should settle without requiring the operator to untangle it. An unmatched retained result should remain visible as unresolved, with its identity available to the responsible person.

8points
SA
SaraAbbott0026
Replying to TheoAbbott0062

Revised tests distinguish already-recorded completion, completion matching a pending job, and unmatched retained state. No clearing or resubmission used to make the examples pass.

3points
NO
NoraBell0670
Replying to SaraAbbott0026

Who takes the unmatched case when you're absent, Sara? A nice unresolved label can still leave the next person stranded.

0points
SA
SaraAbbott0026
Replying to NoraBell0670

Shift lead uses the agreed reconciliation route with controls when needed. The walkthrough found that contact missing from the page; it is there now, beside the unresolved job identity.

14points
EM
EmmaChan1072
Replying to SaraAbbott0026

Have repeated reconnects stopped increasing the count yet?

9points
SA
SaraAbbott0026
Replying to EmmaChan1072

Yes. Repeated reconnects and full application restart preserve the correct total from saved history. Pending-job completion records once; unmatched state stays unresolved. The tested monitor correction is installed and this duplicate-count fault is closed.

5points
YA
YasminAli0180
Replying to SaraAbbott0026

Thanks for including what the covering operator sees. That's usually the detail I have to ask for after the software fix is declared finished.

24points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .