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 · 2026年4月12日 00:30 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
6 条回复
What evidence identifies the request that actually left?
22分回复 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.
18分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.
12分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.
-4分Does reopening after a reviewed decision bring the uncertainty back?
10分回复 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.
14分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .