A function is triggered by an SQS queue with a batch size of 10. If 7 of the 10 messages in a batch process successfully but 3 throw errors, what happens to each message by default, and how does 'partial batch response' (reporting individual item failures) change that behavior?

## What a batch is, and why batching exists SQS-triggered serverless functions receive not a single message but a **batch** — a poller-configured group of up to some maximum count (10 for standard AWS Lambda SQS integrations, more with certain configurations) pulled from the queue in one long-poll cycle and delivered to a single function invocation as an array. This batching exists to amortize the fixed overhead of invoking a function across multiple units of work: - cold-start risk, - per-invocation billing granularity, - connection setup, and to give the consumer visibility into a chunk of the backlog at once rather than one message at a time. ## The default all-or-nothing contract The default completion contract for a batch is coarse: a poll-based invocation either returns successfully as a whole or throws/errors as a whole, and the poller only has that single binary signal to act on. - **If the invocation returns successfully**, the poller deletes every message in the batch from the queue, and they're gone for good, marked processed. - **If the invocation throws an unhandled error** — or times out — the poller treats the entire batch as unprocessed and does not delete anything. Practically, that means it does nothing explicit at that moment; instead, the visibility timeout that was already applied when the batch was received simply expires naturally, and every message in the batch — including any that were, from the handler's own internal perspective, successfully processed just before the error was thrown — becomes visible to other consumers again and gets redelivered on a subsequent poll. ## Why the default is coarse This all-or-nothing default exists because SQS's core contract only understands two outcomes at the API level: delete a message (success) or leave it alone (implicit failure, handled entirely through visibility timeout expiry). Without extra signaling from the function, the poller has no way to know that only 3 of 10 messages actually failed; it just sees 'this whole batch invocation ended in an error' and defers to the visibility timeout mechanism uniformly across everything it delivered. ## The trade-off of accepting it The trade-off of accepting this default is simplicity at the cost of duplicate work: a handler doesn't need any special bookkeeping, but any batch with even one failing message causes full-batch redelivery, meaning already-successful side effects (a database write, an email sent, a payment charged) can run again. - **For operations that are naturally idempotent** — an upsert keyed by message ID, for instance — this is a tolerable inefficiency. - **For operations with real side effects that aren't idempotent**, it's a correctness bug waiting to happen: a redelivered 'charge customer' message can double-charge unless the handler explicitly deduplicates. ## Partial batch response Partial batch response (AWS's ReportBatchItemFailures feature) closes this gap by changing the return contract. Instead of the function needing to succeed or fail as a monolith, the handler: 1. processes each message individually, 2. catches per-message errors internally, 3. and returns a structured list identifying exactly which message IDs failed (typically leaving the successful ones out of that list entirely). The poller then deletes every message not named in the failure list and leaves only the named failures in the queue for redelivery once their visibility timeout expires. This is not automatic — it must be explicitly enabled on the event source mapping and the handler must be written to comply with the exact response shape (an object listing itemIdentifier entries for failures) or the platform falls back to treating the whole batch as failed regardless of intent, a common source of confusion when teams enable the feature but don't update their handler code correctly. | Behavior | Default | Partial batch response | |---|---|---| | Signal the poller acts on | a single binary signal | a structured list identifying which message IDs failed | | Messages redelivered after one failure | every message in the batch | only the named failures | | Duplicate side effects | full-batch redelivery | only the genuinely bad message keeps cycling | ## The operational failure mode it fixes The operational failure mode this feature exists to fix is duplicate side effects at scale: without it, a single consistently-failing message (a malformed payload, a downstream dependency that's down for one particular record) will keep dragging its 9 well-behaved batch-mates through repeated redelivery and reprocessing every cycle until the bad message finally exhausts its maxReceiveCount and gets diverted to a dead-letter queue — multiplying load on downstream systems by the batch size for no reason. With partial batch response enabled, only the genuinely bad message keeps cycling, and the DLQ threshold is reached faster and more precisely because the retry count only increments for the message that's actually failing, not artificially for its neighbors. ## A concrete scenario A concrete scenario: an order-fulfillment worker processes a batch of 10 SQS messages, each representing 'ship this order.' One order references a product ID that was deleted from the catalog, causing a lookup exception. Without partial batch response, all 10 shipping jobs — nine of which already succeeded and, say, called a shipping-label API — get redelivered and re-run, generating nine duplicate shipping labels and duplicate carrier charges. With partial batch response enabled and the handler correctly catching the one bad order's exception and returning only its message ID as failed, the nine good orders are deleted and never touched again, while only the one broken order retries and eventually lands in the DLQ for manual investigation.