# Replay a failed command after the record has changed

Recovery must respect current business state. Test a delayed command against a newer revision before allowing broad replay.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Create a controlled stale operation

Use a synthetic order at revision 7 and create a command based on that state. Force it into the failed-work path without performing its effect.

Then change the order to revision 8 through the normal application. Choose a change that matters to the command, such as cancellation or a different delivery instruction.

Record the expected recovery outcome according to the domain policy.

## Replay through the real worker

Fix the original technical failure and redrive the message through the normal processing boundary. Verify that the worker checks the relevant current state or revision.

The correct outcome may be rejection, review or a recomputed action, depending on the operation. It should not blindly apply the old command merely because the queue now delivers it successfully.

Inspect the stored business result and any external test effect.

## Add duplicate and ambiguous cases

Redrive the same business operation again and confirm it does not repeat a completed effect. Keep transport identifiers separate so the test does not pass only because one delivery identifier remained unchanged.

In another run, perform the external test effect and lose the worker response before recording completion. Verify that recovery reconciles the outcome rather than assuming nothing happened.

These cases test different boundaries and should have separate expected results.

## Mix replay with current traffic

Process new valid commands while replay runs. Confirm that ordering and capacity policy preserve both workloads.

A replayed older update should not overwrite a newer state simply because it arrives later. A large replay should not starve current work unless that priority is intentional.

Save the operation timeline and final state assertions. The exercise passes when the recovery path respects business validity, not merely when the message stops appearing in the dead-letter queue.

## Sources

- [Amazon SQS: redrive behaviour](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-dead-letter-queue-redrive.html)