How Can You Test Duplicate Protocol Delivery?
From the earlier reference collection. Read the current software blog.
Deliver one message twice and verify that deduplication prevents repeating the intended application effect.
Define what counts as the same message
Before writing the test, identify the protocol's duplicate identity: a message ID, event key, delivery token, or another documented field. Make two deliveries with the same identity and otherwise identical payload. The receiver should process the intended effect once if its contract promises duplicate suppression.
Do not assume that identical payloads always mean duplicates. Two legitimate events may carry the same values but have different identifiers. Include a control case with a new identity and the same payload, then verify it is treated as a distinct event when that is the defined behavior.
Observe the effect, not just the response
A receiver may acknowledge both deliveries while performing the business action only once. Track a concrete effect in the test, such as a counter increment, record insertion, or state transition. Assert the stored state after the first delivery and again after the repeated delivery.
Also test a duplicate arriving concurrently if the system processes requests in parallel. Sequential deduplication can pass while two workers race between checking the identifier and committing the action. Use a controlled concurrency test around the storage boundary where the application actually enforces uniqueness.
Include failure and retention behavior
Test what happens if processing fails before the effect is committed and the same message is redelivered. The system should follow its documented recovery policy: it may safely try again, or it may record a terminal failure for manual handling. The test should distinguish a failed attempt from a completed action.
Deduplication records may expire or be retained for a bounded period. If that window matters, test its boundary with a controllable clock. Avoid introducing arbitrary sleeps; advance test time and verify whether a later delivery is still considered duplicate under the contract.
Keep identifiers scoped correctly
Some systems scope message IDs by sender, topic, or account. Add cases where the same token arrives in different scopes if those are meant to represent distinct messages. A globally shared deduplication key can accidentally suppress valid work.
A useful suite demonstrates one repeated delivery, one distinct event, and the relevant failure or concurrency edge. It captures the core guarantee in observable state and helps prevent transport retries from producing repeated application actions.