Amazon SQS's DeleteMessageBatch can return HTTP 200 while some entries failed. Why does it work that way, and what must a consumer do about it?

## Batch means ten independent operations, not one transaction SQS offers batch variants of the three per-message calls: `SendMessageBatch`, `DeleteMessageBatch` and `ChangeMessageVisibilityBatch`. Each accepts up to ten entries in a single request, and — this is the whole point of the question — each entry is evaluated on its own. There is no all-or-nothing semantic. A batch can be entirely successful, entirely failed, or anything in between, and the HTTP status reflects only whether the *request* was well-formed and authorized. So the response is shaped as two lists: ```python resp = sqs.delete_message_batch(QueueUrl=queue_url, Entries=entries) resp["Successful"] # [{"Id": "0"}, {"Id": "2"}, ...] resp["Failed"] # [{"Id": "1", "SenderFault": False, # "Code": "...", "Message": "..."}] ``` Each entry you send carries an `Id` that you choose, unique within that request. It is not the message ID and it means nothing to SQS beyond correlation — its only job is to let you match a result back to the entry you submitted. Keep a local map from `Id` to receipt handle so a failed entry can be retried without guessing. ## Why a delete failure is a correctness problem, not a cosmetic one A failed delete leaves the message on the queue. It is still leased for the remainder of its visibility timeout, so nothing looks wrong immediately — and then the lease expires, the message becomes visible, another consumer receives it, and the work runs a second time. The symptom shows up minutes later and far from the cause, which is why this bug survives code review so often. The failure modes are ordinary: request throttling when a consumer fleet hammers a queue, transient service-side faults, an expired or malformed receipt handle. The `SenderFault` boolean in each error entry tells you which side to blame — `true` means your entry was bad (a stale handle, a duplicate `Id`) and retrying it unchanged will fail again; `false` means it was a service-side or throttling condition and a retry with backoff is the right response. ## What correct handling looks like 1. Build the entries with stable local IDs and keep the `Id` → receipt-handle map. 2. Call the batch API. 3. Iterate `Failed`. For `SenderFault=false`, retry those entries with exponential backoff. For `SenderFault=true`, log loudly with the error `Code` — that is a bug in your code, not a blip. 4. Never treat the absence of an exception as proof the deletes landed. A short retry of the failed subset is usually enough, and it is far cheaper than reprocessing the work. ## Why batch at all SQS bills per request. Batching deletes ten-to-one cuts both the bill and the round-trip overhead on a high-throughput consumer, and the same applies to sends and to visibility changes. The pairing that matters in practice is `ReceiveMessage` with `MaxNumberOfMessages` up to ten, followed by one `DeleteMessageBatch` covering the messages you actually finished — note the *actually finished* part: batching does not license deleting messages whose work failed, and the entries you include should be exactly the ones you processed successfully. ## Two related traps - **Duplicate entry IDs.** The `Id` values must be unique inside a single request; reusing one is a sender fault for that entry. - **Deleting the whole received batch reflexively.** Convenient loops that receive ten and delete ten regardless of per-message outcome turn a partial processing failure into silent data loss. Track outcomes per message and delete only the successes. The rule to carry away: with SQS batch APIs, a 200 is a receipt for the *request*, not for the work. Read the `Failed` list every time.