DineshArcher0386 · 26 Jun 2026, 20:05 UTC
What identifies the retained completion? A job name may describe the work but not distinguish two attempts at it.
2 pointsThe producer retains an attempt reference with the completion, but the monitor only keeps its processed-reference list in memory, so reopening starts that list empty even though the producer still names the old attempt.
8 pointsDoes the saved report already contain that attempt, even when the memory list is empty?
15 pointsKeep the producer's completion separate from acceptance, because your reporting problem shouldn't turn a completed inspection into a quality decision it never carried.
14 pointsI'd test reconnect with one known attempt before changing the handshake. You may already have enough identity to recognise it; the monitor is forgetting its own work. Clearing the producer would make that test easier to pass for the wrong reason.
17 pointsCaleb, the saved report contains it; Luca, acceptance is a separate reviewed field, though the screen's completion count is wrongly increasing, and Nathan, the developer can replay that exact retained state against the saved report.
3 pointsThen should the saved report be the processed record, or does the monitor need a second durable list? I would worry about those disagreeing after another interruption.
11 pointsMina, that's what I'd ask the developer to decide explicitly. Two separately saved facts can create a new gap. In our reporting tool I would want the durable record of the event and its reporting effect to be consistent after a crash, not merely stored somewhere eventually.
17 pointsAnd an unknown retained reference should stay unresolved, not become a request to run again.
8 pointsCaleb, yes, and it needs a visible place in the report so an operator doesn't read an empty progress change as the system having ignored the problem.
8 pointsThe candidate uses one durable event record keyed to the producer's attempt identity, with reporting derived from that record; an unknown retained reference is displayed as unreconciled and does not enter the work queue.
16 pointsWhat happens if the same reference comes back with different result content? I would not want identity matching to hide that disagreement.
10 pointsIt flags a conflict and keeps both observations for review rather than overwriting the saved result; I had not included that case in our first test request, so thank you, Mina, it is there now.
0 pointsThat's a useful addition. Also interrupt the monitor around its durable recording step, then reconnect again; a clean shutdown proves much less about the failure you described.
14 pointsNathan, would you include the screen opening before reconciliation finishes as well, so it doesn't briefly show the retained completion as newly accepted?
18 pointsYes, Luca. The initial screen should say what it knows at that point, with reconciliation pending where appropriate. A later correct count doesn't excuse an earlier confident but unsupported one.
9 pointsHave those interrupted-save replays run yet? Interested in the retained-state case specifically.
12 pointsThey have, Caleb: interruption before the record becomes durable causes one recording on recovery, and interruption after it leaves the count unchanged; repeated reconnects preserve the producer state and never add another event for that attempt.
8 pointsThe unknown-reference and conflicting-content cases also remain visibly unresolved, with no resubmission; startup displays reconciliation pending until it has the durable state, and the reviewed acceptance field stays separate throughout, so the reporting correction is accepted for this commissioning build.
13 pointsThat answers my concern about the second list. The event record now carries the decision instead of depending on whether somebody has kept the monitor window open.
3 pointsBy creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.