Our UR5e fixture-verification helper crashed after sending a sample-housing request but before saving its result; startup resubmits pending work, and that label covers both unsubmitted jobs and requests that may already have continued, so how should I separate those states?
Stop treating all pending records as eligible for automatic submission. Preserve the existing evidence and distinguish known unsubmitted work from sent or uncertain attempts before changing the startup path.
A place-before-save interval exposed a similar bookkeeping assumption in my recovery draft. A file that says the next step has not happened is not evidence that the physical process stopped there. Here the old record must remain uncertain unless another source can establish the attempt's outcome.
I have disabled automatic resubmission of ambiguous records and preserved the file; quality and the station owner need to decide the old attempt's disposition
Make that hold visible to the next shift with the housing and attempt details. A silent skipped row can look like work the application forgot rather than work awaiting a decision.
For the future path, record a durable attempt identity and intent before sending, then preserve the outcome when obtained. But a crash around a write or send can still leave uncertainty. The design needs reconciliation against supported station evidence, not merely more labels in the local file.
Exactly. Do not call the intermediate state sent if the only durable fact is that sending was intended; the failure can occur on either side of the actual submission.
Wouldn't that leave a lot of things on hold unnecessarily? I'm thinking of a crash just before any request goes out, when the station genuinely did nothing.
It can leave a job held until evidence resolves it. That is the unavoidable ambiguity if the application cannot know whether the send occurred. Better correspondence and supported queries may narrow it; renaming the local state cannot prove the station did nothing.
Rachel's practical concern belongs in the recovery design though. The reviewer needs a way to find the relevant station evidence and a defined escalation when it is unavailable, not a screen full of permanent mystery rows.
I can draft the review view with the retained identifiers and uncertainty reason; the old attempt still lacks enough correspondence to assign an outcome
Keep that old disposition separate from the new design. Adding better attempt identities now cannot retroactively distinguish two submissions that the old record did not identify.
That answers my objection. I was imagining held meant forgotten, but you're describing a review path with an owner. I'd want a count on the front screen so the remaining work is obvious.
Test failures around each durable write and submission boundary in a software harness. Include reopening while still unresolved, since the hold must survive another restart rather than become ordinary pending again.
Also show what the operator sees while the reconciliation query is still pending. Starting a query should not briefly label the housing ready to submit.
The draft keeps unresolved visible during reconciliation and across reopening; I have not implemented a station query or claimed the old housing was completed
Use the supported interface contract to decide what a returned acknowledgement proves. Receipt, acceptance and completion can mean different things; a matching identifier without the event meaning may still be insufficient for final disposition.
Who will test the review wording without already knowing your explanation? I'd use someone who covers the station rather than only the person implementing it.
The covering lead will read it with quality; thanks, Rachel, the current draft now shows held-item count and review ownership alongside the attempt evidence
The immediate duplicate-submission risk is contained by the hold, but the new state machine and boundary tests still need completing. Keep that distinction in the handover so nobody reenables blanket retry because the draft looks finished.