The PLC completion was already high before our connection dropped. On reconnect, the application adds another accepted coupon. Or another acceptance entry, to be precise; there was no new inspection. I want the retained state assigned to its actual attempt, without clearing things just to make the display look fresh.
Have the developers identify what attempt reference accompanies that retained completion and whether the application already recorded it, including what survives a restart on each side.
Application stores the job name and its own row number. PLC retains the job name. We reuse the name for successive coupons, so it doesn't identify the attempt.
That resembles our delayed-completion problem: the receiver attached whichever reply arrived to the active attempt. Does yours count immediately on connection, or only after the operator selects the current job?
That is a useful display case, Noah, with the retained observation distinct from a newly accepted result; controls still needs a reliable attempt-matching rule rather than using the screen change to settle ownership.
I would keep the existing total out of any release decision until the duplicate entries are reconciled. Fixing the next connection will not quietly repair the history already counted.
Quality is reconciling the earlier entries, Callum. The draft display holds retained observations separately. The interface owners are defining an attempt reference that survives the relevant restarts.
Does that include the producer restarting and reusing its sequence, Priya? A new field can still repeat if its lifetime is shorter than the record it identifies.
And make the producer-restart case part of the agreed examples, Jonas, with old and new observations both present; it is easier to review that than an abstract promise that the identifier is unique.
Producer restart is now in the examples. Thank you Jonas. We had described application restart in detail and left the other side as 'retained as normal'.
It stays unresolved in the draft, visible but excluded from accepted totals. Quality handles the affected coupon separately. Offline checks of that path are still outstanding.
When those checks run, include an old completion that was legitimately accepted before the outage. The useful behaviour is retaining that one acceptance without earning a second one.