HazelBrooks0832 · 29 Jul 2026, 22:55 UTC
Can your test choose the next delivered event explicitly? Start with one fixed sequence: attempt A starts, attempt B starts, completion A arrives. Assert that B remains incomplete.
19 pointsYes, delivery is ours to control; the sleep was only pretending to be a network delay.
17 pointsKeep a readable event trace when the assertion fails. Otherwise the next maintainer has to reverse-engineer which fictional delay produced the result.
2 pointsI'd give each test a tiny script of events, then reuse the same handler as the application. My first impulse was separate fake logic, but that could test the fake beautifully while missing your actual bug.
10 pointsWhat information distinguishes the attempts in the events you receive, rather than only in the test?
11 pointsCurrently just the job label reaches reconciliation. We lose the attempt distinction before matching the result.
24 pointsThen fixing the scheduling test isn't the whole repair. Establish whether the upstream record carries reliable attempt correlation, and define an unresolved state when it doesn't. Don't infer identity from whichever attempt happens to be current.
2 pointsPriya, would you still keep the job label in the test? I don't want to remove the exact collision Hazel found.
11 pointsDefinitely. Keep the label the same and make the attempts distinct. I meant stop treating that shared label as sufficient evidence, not remove it.
7 pointsAlso try the current completion twice. Different-attempt protection and duplicate handling are different assertions, even if both currently add an extra result.
11 pointsThe deterministic test now fails every time on the old matcher. Thanks, Sarah, it's using the actual handler.
9 pointsThat should make the repair much easier to check. Keep that failing sequence unchanged when you change the matcher.
10 pointsThe revised offline matcher passes old and duplicate completion cases. Missing correlation stays unresolved instead of borrowing the newest attempt.
20 pointsDoes it also preserve the unmatched event for later reconciliation, rather than just drop it?
9 pointsAnd an offline unresolved state must not become permission to repeat a physical operation. The application's real recovery decision still needs its own review.
19 pointsWhen you hand this over, show the missing-correlation example beside a matched late result. That tells support what evidence is absent instead of sending them chasing a timing setting.
20 pointsUnmatched events are retained. Real interface mapping and recovery review remain open; the reproducible offline tests are ready for the maintainer.
7 pointsBy creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.