Our FR5 inspection request may have run after Python crashed, but startup sees the unfinished file and queues it again. I found this while reviewing a saved failure log, not by rerunning the cell. How should we represent an attempt that might already have happened?
It needs an uncertain state that is excluded from automatic resubmission. Pending currently combines two operationally different situations: definitely not sent, and possibly sent with no saved outcome. That ambiguity needs resolving before restart can choose work.
Would writing 'sent' before the network call solve it? That was my first thought, although then a crash could leave a job marked sent when nothing left the PC.
It changes which ambiguity you encounter; it does not remove the gap between local storage and the external action. A durable dispatch-intent record can identify work requiring reconciliation, but cannot prove the receiver executed it.
Who can reconcile that uncertainty now? In our lab the person on the morning shift needed a concrete list of affected samples. A red 'pending' box with no attempt details just moved the guesswork to them.
The recovery path needs an owner and evidence for the specific attempt. A new status name helps only if startup honours it and the operator has a defined way to investigate it.
Currently nobody owns it. The file has the sample identifier and a job counter, but the counter resets. I've flagged the saved incident as uncertain and asked the application owner to disable automatic replay of that class.
The resetting counter also limits matching against remote records. Ask whether the receiver can expose durable outcomes tied to an identity that survives your service restart. Do not assume it can from the current file format.
And quarantine the affected sample's result, not just the software row. Otherwise somebody may use it while the programmers debate whether the job ran.
Agreed. The operational record should distinguish an unknown execution outcome from an accepted inspection result. The quality owner needs to define how that sample is handled while evidence is incomplete.
Please retain the original attempt when it's reconciled, with the evidence and decision attached, because deleting the confusing row gives the next person a very tidy lie.
The application owner has paused automatic restart dispatch for this workflow. We're drafting separate never-sent, dispatch-uncertain and completed states. Quality is deciding the sample disposition; I'm not treating the missing result as a failure or pass.
Can the next shift see why dispatch is paused? Even a clear recovery list helps. Otherwise someone will restart the service again because the screen looks like yesterday's ordinary queue delay.
We've added the incident to the shift handover and named the application owner as the recovery contact. The screen change is still only a proposal; I should not imply the new states are implemented.
For validation, use a controlled test harness to exercise crashes on both sides of dispatch and outcome persistence. The expected result for an ambiguous case should be blocked reconciliation, not an automatic second submission.
Yes. Any authorised repeat must be explicit, linked to the prior uncertain attempt, and consistent with the task's recovery procedure. Closing an incident and submitting new work are different actions.
And hand over the state definitions with those tests, so the next maintainer knows why an old pending file mustn't be casually swept back into the queue.