GabrielBaker0453 · 21 Aug 2026, 20:00 UTC
Can the restart offer be disabled while you establish what evidence exists for each interrupted job?
10 pointsI would distinguish a job known not to have been sent from one whose outcome is unknown, but test the actual save and send boundaries because the names alone do not establish that distinction.
23 pointsNora, how do you know the first category is really unsent? If the saved record is old, pending tells you very little.
16 pointsYou need an enforced ordering in which durable intent exists before dispatch can occur, and even that leaves an uncertain interval after intent is saved; I was not suggesting relabelling the current rows.
2 pointsI've turned off the restart offer in our PC application and kept the interrupted plate aside, and the current row has nothing saying whether dispatch started
16 pointsWhat identifies the plate in the inspection result?
20 pointsDo not recover a queue before you can identify its physical work.
12 pointsDoes the controller retain a result tied to that particular job, rather than merely its latest completed condition?
0 pointsThe plate has an inspection label but the controller result we're reading has no job identity, so I cannot use that last completed value to clear this row
20 pointsThat rules out automatic reconciliation from this value. It doesn't rule out an authorised inspection decision about the held plate. Those are different jobs for the recovery screen.
13 pointsWho can record that decision, with the plate label and reason?
8 pointsAnd does recording an inspection disposition accidentally release another robot job, or can it remain a records-only action?
15 pointsGive relief staff a visible hold, not a retry button with a warning.
9 pointsQuality has identified the plate and kept it on hold while they decide how to inspect it; our software maintainer is separating that decision from any new dispatch
23 pointsWhen the maintainer tests this, include a crash after saving intent but before sending, since that will deliberately produce an uncertain record even though no physical job happened.
8 pointsYes. Otherwise someone will call that test a false alarm and quietly put the automatic retry back.
16 pointsOffline interruptions now leave a hold after intent is saved, whether the fake receiver gets the job or not, and an older pending row also stays held rather than being converted to unsent
13 pointsWhat happens if the held row is opened on a second PC while the first operator is entering their decision?
25 pointsKeep the offline results; they do not establish what the controller retains.
7 pointsThanks Toby, the records-only question caught a shared button handler that could have sent work again; that is separated now, but the second-PC case and the real controller evidence still need work
13 pointsBy creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.