Dead letter recovery

Preserve business identity when a message is redriven

Queue metadata can change during recovery. Put the durable operation identity in the application message and use it at the effect boundary.

In this article

Define the recovery envelope

Include the business operation identity, tenant scope, contract version and original acceptance time in trusted message data. Keep the current transport identifier as separate diagnostic metadata.

Do not use a newly assigned queue message identifier as the only duplicate-protection key. A redrive or republish may change it while representing the same intended action.

Protect any payload fields according to the data they contain.

JSON example
{
  "operationId": "dispatch-example-41",
  "tenantId": "tenant-example-a",
  "contractVersion": 2,
  "acceptedAt": "2026-09-10T03:00:00Z",
  "action": "dispatchOrder",
  "orderRevision": 7
}

This illustrative contract carries the information needed to evaluate an old operation. The worker must validate scope and current business rules rather than trusting arbitrary client-supplied values.

Record failure classification

Save the bounded error category, attempt history and known effect state in a durable record linked to the operation. Keep detailed payload inspection behind appropriate access.

Distinguish a confirmed rejection from an unknown external outcome. Those states should not share an automatic replay action.

Record the consumer version that failed so a contract fix can be linked to the affected messages.

Apply a controlled recovery action

Select a reviewed subset and verify that the underlying cause is resolved. Use the platform's supported redrive or a purpose-built recovery path with clear identity handling.

If message transformation is required, do not assume the native redrive feature can perform it. Amazon SQS documents that its redrive does not filter or modify messages during movement.

Keep original evidence and the repair decision traceable when creating a corrected operation.

Verify and close the operation

Check the business result after processing and save the resolution. An empty dead-letter queue only proves messages moved or expired, not that their effects completed correctly.

Test a duplicate redrive and a worker crash after the effect. The original operation identity should preserve the intended result through both cases.

Keep unresolved items visible with an owner until their outcome is established or a deliberate closure decision is recorded.

Primary sources

Amazon SQS: redrive behaviour

References checked 11 September 2026.