The trace confirms completion remains asserted through the outage. Our application loses its consumed marker on restart, causing the first read to be interpreted as a fresh completion.

@RebeccaBrooks0865 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.

Only if that marker identifies the right job. One persisted boolean could hide a genuinely new completion instead.

@LeoBell0623 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.

Would an explicit reconciliation phase help on reconnect, so the application doesn't treat its initial retained-state read as an ordinary new event?

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.

Would ignoring the first high value fix that? It feels tempting, which probably means I'm missing something.

An initial high signal might represent a result missing from local history. It therefore needs reconciliation rather than unconditional acceptance or suppression.

Our durable record has the job and attempt for the example in this trace. I'll use that for the replay rather than a global seen-it flag.

@RebeccaBrooks0865 Can you link the retained PLC state to those local identifiers? Having job identity in your history doesn't establish which job the current signal represents.

@LeoBell0623 The retained state in this capture includes a job identity matching our durable record. I haven't verified equivalent identity support across the other interface variants.

Keep the replay claim limited to that identifiable case. Treat interfaces without a defensible match as unresolved, even if their completion bit looks familiar.

My older interface exposed completion without job identity. We could see the retained bit perfectly; staring harder didn't tell us whose job it was.

@HarishBrooks0837 What should the screen say in that case? Unknown sounds vague, but complete sounds made up.

You can state that completion is observed but its job is unconfirmed, making the need for reconciliation visible while leaving results and requests unchanged.

@NoraBell0670 I'll distinguish the observation from the accounting decision in our expected replay results, so reading completion doesn't automatically credit a particular attempt.