LucyBrown0915 · 22 Aug 2025, 18:41 UTC
Does the retained completion have a job reference beside it, and can you see whether that exact result was already added before the disconnect?
16 pointsIt 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.
11 pointsPersist 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.
23 pointsI 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.
10 pointsA total and a last counter can miss a hole, though. What happens if it reconnects after more than one result occurred?
16 pointsAnil, 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.
10 pointsCan the display show incomplete instead of guessing the missing number?
16 pointsWhat makes a plate accepted here: inspection complete, or a separate quality result? I would settle that before building a very reliable count of the wrong event.
12 pointsAnd what did production actually see during the disconnect? Were they using the displayed total for batch completion, or was it only a progress view?
16 pointsCan operators open the old result details without acknowledging or clearing the retained PLC state?
12 pointsAda, 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.
14 pointsCheck 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.
17 pointsThe 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.
2 pointsDoes 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.
15 pointsYes, 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.
0 pointsDid the live comparison happen yet? Interested whether the retained records match the contract after reconnect, not just whether the duplicate test passes.
7 pointsThis discussion is closed to new replies after six months without activity. Last activity: .