CallumBennett0708 · 28 Jun 2026, 10:51 UTC
Does the reconnect record contain a job identity, or only the completion bit?
23 pointsI'd preserve the raw reread separately from the counted result. You can observe the same completion twice without producing two completed jobs; throwing away the reread makes the diagnostic history less useful.
14 pointsFiona, would the operator see both entries? I can imagine that distinction being clear to a developer and still looking like two finished coupons on the shift screen.
15 pointsTwo observations in diagnostics, one result in production totals. Label the views. I wouldn't make operators deduce it from timestamps.
-3 pointsChen, the controller record has a job number and completion state but our reconnect handler only passes the state onward; Fiona and Louis, both screens currently use the same event list, so yes, they both show the extra completion
21 pointsI've watched a class treat job number as a permanent identity because the exercise never restarted its producer, so I'd ask what happens to that number at restart before making it the only key here
5 pointsAnd who reconciles the coupon already counted twice? Fixing the display for the next run won't explain the old total. I'd want the commissioning owner to check that against the job evidence, with the correction visible rather than quietly editing the number.
11 pointsSame coupon still in the fixture, Callum, or had it been removed?
12 pointsRuth, that observation could help reconciliation, but the occupied fixture alone would not identify which verification completed. I would keep physical state and the recorded job evidence together.
8 pointsFor a beginner's handover, I'd put one actual reconnect example beside the two screens. Show the repeated observation and where its existing result is found. If identity is missing, the example should stop at unresolved, not supply a guessed number.
8 pointsRuth, it had been removed; the commissioning owner matched the saved record to the identified coupon in the inspection log and has recorded the duplicate-count correction, while the developer is separating observations from results
16 pointsOlivia's example sounds useful. We had a handover full of normal screenshots and no explanation of why yesterday's information might reappear; the person on shift naturally treated every new row as new work. I'd test this wording with somebody who hasn't helped write it.
18 pointsHas the job-number restart question been answered, Callum, since that determines whether a repeated number can safely be matched to the old result at all?
9 pointsOwen and Theo Ali, the job counter can restart from its initial value and this interface exposes no producer-session identifier, so the developer has made that restart case unresolved instead of reusing the earlier result
19 pointsWhat happens on the screen in that unresolved case? I'd expect a reader to know which total is confirmed and which job needs attention, without opening a developer log.
23 pointsAnd don't call that a new completed job merely because its number is unfamiliar.
12 pointsThe replay build shows confirmed results separately and a named unresolved observation with no count increment; held-state reconnect repeats one result, while the restart-number case stays unresolved, and nothing in this monitor resubmits work
7 pointsThat gives maintenance an honest boundary. Keep the producer-identity limitation in the handover with the reconciliation owner, Callum; otherwise somebody will see the unchanged total after a restart and decide the monitor simply needs another reconnect.
10 pointsBy creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.