Our application sometimes counts an old completion again when it reconnects.
The PLC signal was already high before the connection dropped.
This tracks fixture-check bookkeeping for Fairino FR5 in a PLC-coordinated inspection bench, using a sample bracket.
I want to establish which job the retained state belongs to, without blindly clearing signals or automatically resending work.
@IsaacAbbott0085 It stays high. Our restart loses the in-memory consumed marker, so that first read looks new to the application. Annoyingly simple once it's visible.
Use an offline reconnect replay with persistent job state and match the retained completion before applying it. Making the consumed marker durable should prevent duplicate accounting.
A durable marker needs job identity; persisting a generic consumed flag could suppress a different completion rather than correctly deduplicating this one.
@LeoBrown0884 You're right about the missing identity condition. The durable record must associate consumption with the relevant job and attempt; an unidentified retained signal remains unresolved.
@JaneAbbott0075 A reconciliation phase can compare the initial retained state with persistent history before normal processing resumes. Connection recovery alone doesn't establish a new job result.
@IsaacAbbott0085 On my monitor, reconnect reused the startup path and reset the last-seen value. Edge detection then invented an edge nobody had observed.
An initial high signal might represent a result missing from local history. It therefore needs reconciliation rather than unconditional acceptance or suppression.
For this traced example, our persistent history identifies the job and attempt. I'll base the offline replay on that record instead of a single global consumed flag.
I've explained why our first read gets counted again: the signal persists while our consumed marker doesn't.
I'll close the fix only when identity-based reconciliation survives the offline reconnect and restart cases.