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.

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.

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

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

@RachelBell0696 Yes. Read the retained state, compare it with durable history and decide what it establishes. Reconnecting itself isn't evidence of new completion.

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.

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.

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