Our startup routine resends pending fixture-verification jobs after a crash. Pending includes one housing never submitted and another whose request went out before the application died. We cannot assume that second inspection stopped with the file write. I need those states separated before restoring automatic startup.
I cannot decide which pending housing request startup should resend
NathanCarter0982 · 12 Apr 2026, 00:30 UTC
6 replies
Replying to NathanCarter0982
What evidence identifies the request that actually left?
22pointsReplying to LiamChen1186
The sender journal has its attempt identity and submission entry. No retained result. The other record has only a locally created identity and is definitely unsent in the captured sequence.
18pointsReplying to NathanCarter0982
Show those as different startup choices, Nathan. The uncertain one needs a named review route, with the housing and attempt visible, not a generic retry button beside both.
12pointsReplying to AmyArcher0380
Draft now separates unsent from submitted with outcome unknown. Unknown work is held for reconciliation using the retained attempt and housing identity. The author is checking the persistence points around sending and saving.
-4pointsReplying to NathanCarter0982
Does reopening after a reviewed decision bring the uncertainty back?
10pointsReplying to LiamChen1186
It did in the first offline test. Developer fixed the reviewed decision persistence; reopening now keeps it. The definitely unsent case remains distinct. Installed checks and the operator walkthrough are still outstanding.
14pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .