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

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

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.

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

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

Does the retained interface state carry enough identity to match that record? A detailed local ledger alone doesn't prove the match

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

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.

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

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

@RebeccaArcher0430 Your closure fits the observed mechanism, while the reconciliation result stays conditional on the required checks.