Retry Side-Effect Auditor

Verdict — DUPLICATE-EFFECT-RISK

Two irreversible effects can occur outside the database transaction, and enforcement of a stable provider idempotency key is not shown. A retry may create a second charge or receipt even when the database ultimately contains one paid order.

Operation boundary

Business identity: order_id. Retry initiator: queue redelivery after worker timeout. Completion signal: message acknowledgement. The acknowledgement occurs after all effects and therefore cannot prove which effects completed before a crash.

Side-effect ledger

Adversarial retry matrix

• Duplicate: charge and email can repeat after acknowledgement loss.
• Partial: payment can succeed before the status transaction commits.
• Concurrent: two workers can reach the provider unless one stable key is enforced at the provider boundary.
• Reordered: receipt may be sent before durable order completion.
• Poisoned: repeated failures may outlive an unspecified dedupe-retention window.

Required contracts

Propagate order_id or a stable derived operation key to the provider. Enforce one durable order transition. Record an email dispatch key with a uniqueness constraint. Compensation must be idempotent and observable; a refund action cannot itself create a second refund.

Discriminating tests

1. Crash immediately after provider success and before the database commit, then replay the same queue message.
2. Deliver the same message concurrently to two workers.
3. Crash after the paid status write but before email dispatch.
4. Replay after the documented dedupe-retention window.

Validator

The demonstration includes all five retry scenarios and all required effect fields and passes the bundled structural validator. No payment, email, queue, or production system was executed.