DominicBailey · 24 Sept 2025, 04:39 UTC
Can your test choose when each message is delivered?
23 pointsAt the moment a background thread sleeps and sends it, so the machine running the test gets a vote in the order
8 pointsReplace that timing guess with an event queue the test advances explicitly.
16 pointsWrite down the bad sequence in the test itself. Old attempt waits, new attempt starts, old completion arrives. Then check the new attempt is still unfinished, not just that the test printed the right warning.
15 pointsDoes the completion carry an attempt identity?
15 pointsOnly the job label in my model, which is exactly what gets reused; the software owner is reviewing how the real interface can carry attempt identity
17 pointsKeep the reused label in the test. It is part of the failure case.
22 pointsCan you reproduce it now without any sleeps?
6 pointsYes, Liam, queued delivery fails the old handler every time I've run it, and Daniel's unfinished-state assertion catches the wrong completion directly
20 pointsGive the test separate identities for separate attempts. Deliver duplicates as well as the delayed event, and check that a completed attempt cannot be credited twice. Keep the real interface work separate from this model change.
18 pointsAdded unique attempt identities in the model and the delayed case now passes, but a duplicate still adds another entry to the completion list
2 pointsThere's your next assertion. One accepted completion entry per attempt. I'd also want the ignored duplicate visible somewhere for diagnosis, because otherwise support will wonder why the raw message count differs.
15 pointsThe model now retains the duplicate as an event without crediting another completion; or rather, that's what the new handler does, and the old handler fails both checks
19 pointsWhat happens if the application restarts before the duplicate arrives?
23 pointsAnd does the test restore saved state or start empty?
14 pointsRestore the state the application design actually persists. Include a crash after receipt but before saving the completion. Recovery has to handle that uncertainty rather than assuming the event never occurred.
23 pointsLiam, it started empty, which was no help; I've added saved-state restoration and a crash point before the save, Elliot, with the unresolved case left for reconciliation
7 pointsAlso deliver the new attempt's valid completion before the old one. The old event must not overwrite the newer result or reopen a completed attempt.
19 pointsWho will read the unresolved case screen? Your software owner should try the wording with them. 'Unknown' without the attempt or reason sends people straight back to asking you.
22 pointsQuality's shift lead will review that screen, Daniel; model tests now cover both completion orders, duplicates and the save gap, but the live interface proposal is still with its owners
11 pointsThis discussion is closed to new replies after six months without activity. Last activity: .