Which housing jobs can startup still submit after this crash?

NathanArcher0373 · 20 Aug 2026, 14:26 UTC

Reply to discussion
NA
NathanArcher0373
My UR5e inspection application crashed after sending a housing request but before saving its answer. Startup resends everything marked pending, including untouched jobs and possibly completed ones. What can I separate without guessing what the receiver did?

16 replies

PR
PriyaBarnes0568
Replying to NathanArcher0373

Stop blanket resubmission first; pending is not evidence that a request never left.

22 points
AN
AnnaBell0677
Replying to NathanArcher0373

Who can reconcile a housing when the file and the receiver disagree?

9 points
AM
AmyBennett0728
Replying to AnnaBell0677

Anna's question needs an actual person, but they also need somewhere to leave it undecided. A supervisor choosing between resend and complete is still guessing if both buttons require evidence they haven't got.

16 points
NA
NathanArcher0373
Replying to PriyaBarnes0568

Automatic resend is disabled. The cell lead owns reconciliation; the existing file only has pending or done.

10 points
DA
DavidBrooks0867
Replying to NathanArcher0373

I'd make a small offline copy with a housing that has definitely never reached the send step and another stopped after that step starts. Restart both. You want to see the first eligible for normal submission and the second held for reconciliation, without needing a robot to demonstrate the difference.

22 points
AM
AmyBennett0728
Replying to DavidBrooks0867

David, a send-step flag written afterwards leaves the same crash gap. The durable record has to capture the intent before the possible external effect, and a crash there still leaves uncertainty rather than proving delivery.

13 points
DA
DavidBrooks0867
Replying to AmyBennett0728

Yes, I was too loose about the boundary. I meant a persisted intent before calling out, not a note afterwards. The test should interrupt on both sides of that write as well as around submission and result storage; otherwise it can pass while keeping the original hole.

15 points
AN
AnnaBell0677
Replying to NathanArcher0373

Does reopening a held record preserve the hold, or quietly turn it into pending again?

8 points
PR
PriyaBarnes0568
Replying to DavidBrooks0867

Also test an old saved result arriving after restart. It must not complete a different attempt.

7 points
NA
NathanArcher0373
Replying to AnnaBell0677

Found that exact reopen problem in the offline copy. Unknown states were loaded as pending by default.

8 points
AM
AmyBennett0728
Replying to NathanArcher0373

That default needs a test of its own. Include a state the current program doesn't recognise, not just the new hold state, so an older installation cannot silently reinterpret a newer file as work to send.

11 points
DA
DavidBrooks0867
Replying to AmyBennett0728

And keep the original file format version with the record. I'm not suggesting the software magically understand a future format; refusing to offer submission is a valid response when it cannot interpret the evidence it loaded.

9 points
NA
NathanArcher0373
Replying to AmyBennett0728

Parser now refuses unknown states. Repeated reopen preserves the uncertain housing, and the unsent example stays separate. Receiver lookup still unconfirmed.

20 points
AN
AnnaBell0677
Replying to NathanArcher0373

Then the lead needs an unresolved list, not a promise that every held housing will be recoverable.

20 points
NA
NathanArcher0373
Replying to AnnaBell0677

Added that list. Offline crash tests pass around intent, send and save; actual receiver correlation remains with the integrator.

10 points
PR
PriyaBarnes0568
Replying to NathanArcher0373

Keep automatic retry off for those legacy pending records; the new parser cannot reconstruct their missing history.

4 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.