A notification worker can time out after the provider has already accepted its request. If the worker treats every timeout as a confirmed failure, its next attempt can create a duplicate.

A useful test begins with the order of events:
1. The provider records acceptance.
2. The response does not reach the worker.
3. The worker must decide what to do with an uncertain result.

A fake that throws before acceptance tests a different failure. To expose the duplicate risk, make acceptance happen first.

Track three observations separately: calls made to the provider, effects accepted by the provider, and the worker’s recorded state. An exception describes what the caller observed. It does not establish what happened remotely.

Next, compare two retry policies.

With a provider that supports the required idempotency contract, use one stable identity for the logical notification. Keep that identity and the notification content unchanged across attempts. A newly generated identity on every retry makes it harder for the provider to recognize the same intended operation.

That guarantee remains conditional. Check the provider’s identity scope, retention period and behavior when a key is reused with different content. In a persistent worker, recovery also needs to preserve the operation’s identity.

Without a usable idempotency guarantee, an automatic resend after an ambiguous result may duplicate the effect. Preserve the uncertainty and keep it out of the ordinary resend path until stronger evidence or an explicit duplicate-risk policy resolves it.

Provider acceptance and final delivery should remain separate states. Acceptance alone does not prove that the recipient received the notification.

The same review should extend beyond the timeout:
- After committed work is recovered, can two workers compete for it safely under the implementation’s tested conditions?
- Can a duplicate receipt repeat a transition?
- Can a stale receipt move state backward?
- What evidence actually allows an uncertain outcome to become confirmed?

For a runnable first experiment, try the free Java sample: https://adrianstudio3.itch.io/notification-timeout-lab-free-java-sample. It is a separate MIT-licensed, single-scenario Java 21 lab with seven checks against an in-process fake provider. It requires no third-party dependencies, database, Docker or network. All state is in memory; provider acceptance is not actual delivery.

Notification Failure Lab for Spring Boot packages these questions into educational Java and SQL source, synthetic fixtures, an intentionally broken baseline, a reference implementation and automated tests. It covers persisted-work recovery, accepted-request timeouts, and duplicate or out-of-order receipts.

The documented local run used PostgreSQL 16.15 through Testcontainers: 15 tests passed, with none skipped. Three passing baseline tests demonstrate intentional defects; twelve exercise reference behavior. A green suite therefore requires reading what the tests assert.

The kit is source-only and requires JDK 21, Docker and initial dependency/image downloads. It uses an in-process fake provider. Recovery reconstructs a store after commit; it does not terminate and restart a JVM. External fencing, authenticated receipt adapters, retry budgets, operational reconciliation tooling and multi-tenant isolation are outside its scope. It does not certify production readiness or universal exactly-once delivery.

The Notification Failure Lab https://adrianstudio3.gumroad.com/l/iqwjwr is USD29 once for one named purchaser.