Opening the report counts our last plate again

It has a job counter. The client doesn't save which counter it counted, only the total. Closing the window loses the local last-seen state. That's why reopening makes another edge.

Persist the identity of a processed result with the count update, under an agreed recovery design, so a crash cannot save one without the other and recreate the duplication through a different gap.

I would make the report rebuildable from accepted result records. Then the total is an output, not the only surviving clue to what happened. You still need a reliable identity for each result.

A total and a last counter can miss a hole, though. What happens if it reconnects after more than one result occurred?

Anil, we only retain the latest completion at present. Elliot, I prefer a result list too, but it won't invent results the interface never delivered. Controls is reviewing retrieval and counter reuse.

Can the display show incomplete instead of guessing the missing number?

Can operators open the old result details without acknowledging or clearing the retained PLC state?

Ada, acceptance is a separate result field, and we were checking it. Harish, production uses this for progress only, with a separate batch check. Liam and Emma, the draft shows incomplete and lets them read history without clearing anything.

Check how result identities behave across a PLC restart as well as a client restart, since persisting a counter locally will not help if the receiver later reuses that counter for unrelated work.

The revised contract adds a run identity and retrievable result records. Our offline report rejects duplicate result identities and leaves gaps visible. Counter reuse across different runs is covered in those tests. Real-interface comparison remains outstanding.

Does rebuilding the report produce the same count as processing those records live? I'd compare both with a duplicate and an out-of-order delivery in the test set.

Yes, for the offline set we have. Thanks, Elliot. The rebuild caught an ordering assumption that our incremental test missed. This still doesn't recover the historical results lost by the old interface.

Did the live comparison happen yet? Interested whether the retained records match the contract after reconnect, not just whether the duplicate test passes.