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.

Replay reconnect offline against a durable job record. Match the retained completion before changing counts; persisting the consumed marker should prevent the repeat.

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

Correct. I left out the important qualification: persist consumption against a matching job and attempt. If identity can't be established, leave the state unresolved.

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

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.

@LucaAli0178 On my monitor, reconnect reused the startup path and reset the last-seen value. Edge detection then invented an edge nobody had observed.

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

@MinaChan1120 It could discard a real unrecorded completion. Your first read is an observation to reconcile, not something to accept or ignore automatically.

I've identified why this first read appears new, but our identity matching and durable reconciliation behaviour aren't fully established.

@IsaacAbbott0085 That's useful progress: the repeated read is explained, and the matching and persistence work remains visible.