The producer retains an attempt reference with the completion, but the monitor only keeps its processed-reference list in memory, so reopening starts that list empty even though the producer still names the old attempt.

Does the saved report already contain that attempt, even when the memory list is empty?

I'd test reconnect with one known attempt before changing the handshake. You may already have enough identity to recognise it; the monitor is forgetting its own work. Clearing the producer would make that test easier to pass for the wrong reason.

Then should the saved report be the processed record, or does the monitor need a second durable list? I would worry about those disagreeing after another interruption.

Mina, that's what I'd ask the developer to decide explicitly. Two separately saved facts can create a new gap. In our reporting tool I would want the durable record of the event and its reporting effect to be consistent after a crash, not merely stored somewhere eventually.

And an unknown retained reference should stay unresolved, not become a request to run again.

Caleb, yes, and it needs a visible place in the report so an operator doesn't read an empty progress change as the system having ignored the problem.

What happens if the same reference comes back with different result content? I would not want identity matching to hide that disagreement.

It flags a conflict and keeps both observations for review rather than overwriting the saved result; I had not included that case in our first test request, so thank you, Mina, it is there now.

That's a useful addition. Also interrupt the monitor around its durable recording step, then reconnect again; a clean shutdown proves much less about the failure you described.

Nathan, would you include the screen opening before reconciliation finishes as well, so it doesn't briefly show the retained completion as newly accepted?

Yes, Luca. The initial screen should say what it knows at that point, with reconciliation pending where appropriate. A later correct count doesn't excuse an earlier confident but unsupported one.

Have those interrupted-save replays run yet? Interested in the retained-state case specifically.

They have, Caleb: interruption before the record becomes durable causes one recording on recovery, and interruption after it leaves the count unchanged; repeated reconnects preserve the producer state and never add another event for that attempt.

That answers my concern about the second list. The event record now carries the decision instead of depending on whether somebody has kept the monitor window open.