A retry loop creates repeated failures or duplicate effects

Understand the likely causes

• Permanent invalid input may be treated as transient, retry routing may have no terminal owner, or the effect may complete before its acknowledgment becomes certain. A new identity on every retry prevents useful duplicate recognition.

Identify what is repeated and why

Collect stable operation identity, source queue/vhost, sanitized failure category, redelivery evidence and relevant dead-letter history. A redelivered flag is not a complete business uniqueness database, and x-death entries are grouped by queue and reason rather than counting every handler attempt universally. Compare payload version and content so an identity conflict is not hidden as an ordinary retry. A deterministic schema error will not be repaired by immediate requeue. A temporary provider failure needs a bounded delay and deadline. Preserve original evidence before any authorized correction or replay changes the apparent history.

Review retry bounds and terminal transfer safety

Map each return path and identify its terminal destination and review owner. Quorum queues in this 4.1 teaching baseline have the default delivery limit introduced in 4.0; disabling it to quiet an alert can remove protection against poison-message loops. An application republish and a broker redelivery can have different counters, so define the convention explicitly. A named DLX alone does not guarantee safe transfer to an available target. Quorum at-least-once dead-lettering has specific prerequisites and retained-resource consequences, while default transfer can lose messages. Changing strategy during an incident can affect already retained dead letters and requires review.

Check whether the effect already exists

Place destination acceptance and consumer acknowledgment on the same timeline. A crash after the external action and before acknowledgment certainty permits legitimate redelivery of an already applied operation. Checking a volatile seen set does not protect a durable notification, and storing a marker separately can create another crash window. Use a destination-supported atomic identity-and-effect protocol or explicit reconciliation design. The offline ledger shows three deliveries for two operation identities only; it does not certify durable deduplication. Repeated publication must retain the original occurrence identity, while a genuinely new business operation needs a distinct one.

deliveries = ['label-P17-v1', 'label-P17-v1', 'label-P18-v1']
unique_operations = set(deliveries)
assert len(deliveries) == 3
assert len(unique_operations) == 2
print(len(deliveries), len(unique_operations))

3 2

Recover bounded work without hiding missing coverage

Classify invalid input into a reviewed terminal state, repair transient dependencies and prepare any replay against a finite operation set. Account for ordering changes introduced when a failed key moves to another queue while later updates continue. Reconcile missing and duplicate destination results before declaring the incident complete. This guide runs no consumer, changes no delivery limit and republishes no message. An authorized verification should include invalid schema, temporary failure, target unavailability and effect-before-ack interruption, showing one accepted result or explicit terminal outcome per required unique operation.

Keep it from recurring

• Keep immutable occurrence identity, finite retry budgets, documented dead-letter safety and destination idempotency together in the application contract. Review them whenever queue type, retention, replay scope or provider behavior changes.