简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
RuthCampbell · 2026年6月21日 09:02 UTC
What did you actually observe after reopening: another outgoing request, or another inspection cycle? Those are different failures to establish.
18分I'd remove uncertain entries from the runnable list first. No new hardware needed to stop the file's vague wording from becoming a second command.
4分Our retry problem also reached the report. Count identity separately from whether another execution is permitted.
10分Victor, the outgoing request is logged again; I cannot establish a second physical cycle from what we retained. Beth, pending currently has no distinction for possibly sent.
3分Beth's hold is sensible, but don't label every uncertain job failed. Ruth's first execution might have finished perfectly while the application was having its own bad afternoon.
8分Mark, the screen needs to say what is uncertain too, because an operator seeing failed will reasonably expect retry to be the next action.
18分Who is authorised to reconcile the bracket's physical condition with that uncertain entry?
5分I want that job to remain visible. A separate state is useful. Moving it out of sight would only exchange a repeat request for forgotten work.
11分Lin, yes, held and visible. I meant remove it from automatic dispatch, not remove the entry. The review itself also needs to survive another application restart.
16分Sam, our cell lead will own the physical review; Lin and Beth, I'll keep the entry on the main screen with automatic dispatch disabled while its status is uncertain.
18分Does the controller side retain anything tied to this particular request, rather than just a current finished flag?
19分A finished flag alone won't identify Ruth's job. We needed identity to stop repeated observations becoming repeated counts.
23分Hana, same warning for a new number after restart. Giving the retry a fresh identity doesn't make it new physical work or prove the first attempt did nothing.
7分Victor, not enough retained detail to tie the current flag to this request. The cell lead has the bracket held for review; I haven't declared either execution finished.
20分That wording is useful, Ruth; could the review screen also show the last known send and why the result is missing, without presenting the flag as an answer?
3分For the software check, interrupt it around each save and send boundary with dispatch mocked. Then reopen during review. I would want to see no automatic request for every uncertain case.
20分Ruth, has the startup change been exercised yet? I am interested in what the operator sees on the second reopen, not just the first.
8分And who can release that hold after the cell lead's review?
7分The mocked restart checks now leave possibly sent work held, including a second reopen, and the screen shows the last recorded send; physical review and the release responsibility are still open.
14分Useful software progress. Keep the unresolved release ownership beside it in the handover; the mock proving no resend doesn't settle what happens to this bracket.
18分