Our application sometimes counts an old completion again when it reconnects. The PLC signal was already high before the connection dropped. This tracks sample verification tracking for Fairino FR5 in a PLC-coordinated inspection bench, using an inspection coupon.
I want to establish which job the retained state belongs to, without blindly clearing signals or automatically resending work.
@RebeccaArcher0430 Check whether the PLC trace shows a continuous completion signal, then compare that with how your application preserves its consumed-event state across reconnect or restart.
@HassanChan1052 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.
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.
@HassanChan1052 Should reconnect have a reconciliation state before normal monitoring resumes? Otherwise our first sample looks just like any other update.
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.
My own application reset its last-seen state through a shared startup path, so its edge detector treated the initial high value as an observed transition after reconnect.
@SamBarnes0594 An initial high signal might represent a result missing from local history. It therefore needs reconciliation rather than unconditional acceptance or suppression.
@HassanChan1052 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.
@AaronBell0610 In this captured example, the retained job identity matches our record. I haven't established that every interface variant provides the same information.
@RebeccaArcher0430 You can verify the captured case without claiming all variants are covered. Where the interface can't establish identity, the retained completion should remain unresolved.
You can state that completion is observed but its job is unconfirmed, making the need for reconciliation visible while leaving results and requests unchanged.
@HassanChan1052 I'll distinguish the observation from the accounting decision in our expected replay results, so reading completion doesn't automatically credit a particular attempt.
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.