Our offline FR10 tracker completes the current plate attempt when I deliver a delayed completion from its previous attempt. Both belong to the same plate label. I can produce it by hand, but the random-delay test only catches it sometimes. I'd like a test another maintainer can reproduce without my timing tricks.
Replace the sleeps with named delivery steps. Register the first attempt, hold its completion, register the second, then release the held message and inspect the second attempt immediately.
I can queue the messages in the test harness. Our completion payload has an attempt number, but the matching helper currently uses only the plate label.
Keep the existing bug for the first run of the new test. It should fail exactly at that old delivery, so you know the test actually catches what you're about to fix.
Does the stored accepted count change too, or only the screen? I ask because we repaired a display once and the report still included the wrong job... took a rather annoying stock count to discover that.
The queued test fails where expected with the old code. Matching on the full attempt reference fixes that sequence, and the current completion still records once after duplicate delivery. Thanks Farah for the positive case.
What happens when the application restarts between those deliveries? Or rather, what does your test restore then? A fresh empty history could hide a duplicate the live app must remember.
Restart isn't covered yet. I'll restore the same persisted attempt history the application uses, with the old message still waiting in the harness queue.
Check how those attempt references stay unique after restart too. The first test is useful progress, but a reused number would let the old completion find a new home again.