Before you press redrive

The queue looks beautifully empty

The dead-letter queue is shrinking, which looks like recovery until the same messages start failing again in the source queue. Moving them has changed where they wait, not whether the requested work happened. Before pressing redrive, I would want to identify the operations behind that encouraging depth chart: which completed, which need repairing and which still have an uncertain result outside the queue.

A dead-letter queue buys a chance to investigate. The message can tell us what was requested, but the recovery decision also needs its history: how far processing got, whether the data is right and whether the action is still wanted. None of those questions is answered by moving the instruction. A wrong destination remains wrong, and an uncertain send does not become unsent because it has acquired another journey through the transport.

Consider four invented histories behind the queue. One customer’s welcome was sent before the worker crashed. Another could not be read by the consumer. A third has the wrong address, and a fourth reached the provider without returning a known result. They may share an error label, but they need four different recovery decisions. The downloadable manifest names them W17 to W20 so each decision can be followed through the recovery.

Separate the delivery from the intention

Start with the welcome already sent. The provider accepted it, but the consumer crashed before recording completion. Recovery gives its instruction a new queue identity. If the consumer recognises only that identity, it sees new work and sends again, although the customer never asked for another welcome. The ledger follows this as W17, with transport identities m101 and r901; those names explain the two deliveries, rather than two intended messages.

Keep the welcome’s business identity independent of its delivery identifiers. welcome:W17 names the intended effect; a queue identity names an attempt to carry its instruction. Record the known provider operation alongside it where available. AWS’s discussion of idempotent APIs explains why recording a caller-provided identity and performing its effect need careful service-side handling. [3] Remembering queue IDs alone cannot establish that the original welcome happened once.

Amazon SQS documents that redriven messages receive new message IDs and enqueue times, with retention reset. [1] That is a useful transport behaviour, but a poor basis for deciding whether a customer should receive another welcome. A business record must survive the redrive. Conversely, reusing an old business identity for a genuinely changed action can suppress a correction that should happen. The identity has to express intention, rather than merely be stable at all costs.

Three repairs that a move cannot perform

W18 failed before sending because the consumer could not read payload version 1. If that version belongs to the agreed supported contract, a compatible consumer may be all that is needed before a controlled release. Check it against an original specimen and deploy the repair first. Rewriting the backlog to fit the new consumer would be convenient for the consumer, but it could quietly make the recovery tool responsible for disguising a breaking change.

W19 is different: its destination address is wrong. A compatible parser would only help deliver the wrong instruction more efficiently. Preserve the original and record a reviewed correction linked to it, including who changed the address and why. Whether the correction replaces the original business operation or starts a new one is a domain decision. For a welcome never sent, a revised destination might supersede it; for a message already delivered, a later correction cannot pretend the original delivery never happened.

Native SQS redrive does not support modifying or filtering message contents during the move. [1] W19’s address correction therefore requires a separate process. An application-specific recovery tool can read, validate and create a revised instruction, but its authority and history need to be designed explicitly. The operator should be able to distinguish an unchanged redrive from a reviewed correction that creates or supersedes business work.

For W20, changing data is not yet the issue. The provider outcome is unknown. A second send might duplicate the first; dropping it might leave the person without the message. Use the provider reference, query facilities or a reconciliation path to establish what happened. If the available evidence cannot settle it, retain an explicit unresolved case with a named decision. A redrive count is not evidence that an external effect did or did not occur.

Time can make an old instruction wrong

Suppose W18 has waited while the customer closes the account. Even after the parser is fixed, the welcome may no longer be appropriate. Preserve the original event time and check the current business preconditions before producing an effect. This does not mean rewriting history to match the latest record. It means distinguishing a historical instruction from present permission to carry it out.

Queue timing deserves similar care. For standard SQS queues, the documented dead-letter retention calculation continues from the original enqueue timestamp, while the dead-letter age metric describes time since arrival there; FIFO behaviour differs. [2] A recently populated dead-letter queue is therefore not a promise that every message has a full fresh retention window. Check the queue type and actual timestamps before designing an investigation around a comforting dashboard age.

Ordering needs its own check. SQS says redriven messages can interleave with new producer traffic. [1] An older activation can therefore meet a newer cancellation on its way back through the system. The application has to decide what those actions mean together; the FIFO label cannot recover an ordering guarantee changed by the recovery route. Inspect the resulting business object as well as the completed move task, or the transport can report success while the customer ends up in the wrong state.

Recover a small, identifiable set first

A recovery manifest can contain the business identity, original payload version, original transport identifiers, known external outcome, proposed disposition and the evidence supporting it. The four-row resource here is a planning example, not an executable queue tool. For a real backlog, add the exact selection rule and the time it was evaluated. Otherwise the phrase “the failed messages” quietly changes meaning as fresh failures arrive.

Release a set whose outcomes someone can inspect. Keep the completed welcome completed; repair the supported payload, hold the wrong address for correction and investigate the uncertain send. Compare those dispositions with the original selected operations, not only moved or deleted message counts. If three messages disappear but only two operations have an explained ending, investigate the gap: expiry, an incorrect success response or another retry route can all remove a message from view. New traffic makes the overall depth chart less helpful because it mixes these selected cases with fresh arrivals.

Decide the stop conditions before starting: the original parser error returns, duplicate effects appear, new traffic falls behind, or operations enter a state the recovery plan does not explain. Slowing or cancelling movement limits further work; it does not undo effects already performed. Preserve enough identifiers to inspect the portion that has crossed the boundary instead of restarting the whole exercise because its final total is inconvenient.

A straightforward redrive is useful when the failure was temporary, the original payload is still valid and the consumer can recognise the same business operation. That may be W18 after its reader is repaired. It is not yet W19 with its wrong address or W20 with an unknown provider result. The queue chart remains useful for controlling movement; these individual histories tell us whether the person waiting for a welcome has reached the right outcome.