When our monitor reconnects, a completion signal retained from before the outage can be treated as a new completion. We're tracking sample verification tracking with Universal Robots UR5e in a fixture-checking station under commissioning, using a sample bracket. I'm trying to reconcile the signal with its job, without automatic resubmission or simply clearing the retained state.
Replay reconnect offline against a durable job record. Match the retained completion before changing counts; persisting the consumed marker should prevent the repeat.
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.
@FelixAli0197 Would an explicit reconciliation phase help on reconnect, so the application doesn't treat its initial retained-state read as an ordinary new event?
@TheoAdams0149 Yes. Read the retained state, compare it with durable history and decide what it establishes. Reconnecting itself isn't evidence of new completion.
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.
@ImranAllen0305 The duplicate-read mechanism is clear from our trace. A completed fix still depends on persistent, identity-based reconciliation passing the offline reconnect and restart checks.