# Your retry logic is correct and does nothing > Source: > Published: 2026-08-24 18:12:14+00:00 A comment on one of my posts sat open as an issue for two weeks before I understood how bad the thing it described actually was. The post was about an AI assistant missing the SQS trigger on a Lambda. Mads Hansen replied with a sentence I have not been able to unthink since: the trigger shape is the first contract, delivery and retry semantics are the second. Getting `event.Records[0].body` right tells you how to read a message. It tells you nothing about what happens when one of ten messages in a batch throws. I filed it as [issue #87](https://github.com/Sidd27/infrawise/issues/87). The first item on that list is a bug no code reviewer can catch by reading the code, because the code is fine. Here is a batch consumer. It is the shape you get if you read the AWS docs and follow them. ``` js export const processOrders = async (event: { Records: { messageId: string }[] }) => { const batchItemFailures: { itemIdentifier: string }[] = []; for (const record of event.Records) { try { await handleOrder(record); } catch { batchItemFailures.push({ itemIdentifier: record.messageId }); } } return { batchItemFailures }; }; ``` Nine records succeed, one throws, and the handler reports exactly the one that failed. That is the entire point of a partial batch response: the nine that worked are deleted from the queue, the one that failed comes back on its own. Except this handler does not do that, because whether anyone listens to that return value is not decided in this file. It is decided by the event source mapping. If `FunctionResponseTypes` on the mapping does not contain `ReportBatchItemFailures` , Lambda discards the array. The whole batch is marked failed. All ten records are redelivered, including the nine that already ran to completion. The failure mode is duplicate processing. Nine orders get handled twice, or twenty times, because one poison message keeps replaying its batch until the queue's retry limit. If your handler is not idempotent, that is double-charged customers, not a log line. Read that handler again with a critical eye. There is nothing wrong with it. It builds the array correctly, it uses `messageId` as the identifier, it catches per record rather than around the loop. A unit test that feeds it ten records and asserts one entry in `batchItemFailures` passes. That is what makes this different from an ordinary bug. The code is not wrong. It is inert. The half of the contract that would make it work lives in a Terraform module in a different repository, or in a CDK stack a different team owns, or in a checkbox someone clicked in the console eighteen months ago. Nothing in your editor, your linter, or your test suite has any visibility into it. And an AI assistant, asked to "add partial batch failure handling to this consumer," writes exactly the handler above and reports the job done. It is not hallucinating. It wrote the only half it can see. When I built the check into [Infrawise](https://github.com/Sidd27/infrawise), it became clear the mismatch has two directions and they are not equally bad. The first is the mapping-side gap. `MissingPartialBatchResponseAnalyzer` looks for an `sqs` , `kinesis` , or `dynamodb` trigger with a batch size above 1 and no `ReportBatchItemFailures` . A batch of one has nothing to partially fail, so it is skipped. This one is graded **medium**: it is a missing capability, but the handler may genuinely not need it. The second is the mismatch. `BatchResponseMismatchAnalyzer` fires when the code builds a `batchItemFailures` array and the mapping for that trigger has the setting off. That is graded **high**, and the description says why: The code reads as correct and its unit tests pass; only the mapping tells the truth. A missing setting is an absence. A mismatch is an active false belief — someone wrote the handler on purpose, believing per-record reporting was on. Every downstream decision they made about idempotency rests on that belief. Detecting the code side is cheap. Both scanners just match the name: ts-morph looks for a property or shorthand property called `batchItemFailures` , and the Python scanner matches the same dict key. There is no control-flow tracing to a return statement, because building an array by that name has no other purpose in a Lambda handler. The infrastructure side costs nothing either. `FunctionResponseTypes` rides on the `ListEventSourceMappings` response that trigger extraction already pages through, so the whole check is a field carried forward plus two analyzers. One detail mattered more than the analyzers themselves. Both checks fire only on an explicit `false` : ``` // Only an explicit false is evidence. undefined means the mapping was // never read, and this finding would be an accusation without evidence. if (trigger.reportsBatchItemFailures !== false) continue; ``` If a `lambda:ListEventSourceMappings` call was denied by IAM, or the page failed halfway, the field is `undefined` , not `false` . Treating that as "the setting is missing" would produce a high-severity finding about a mapping nothing was ever read from. That failure would be worse than staying silent. A tool that occasionally accuses you of a bug you do not have gets muted, and then it is not there on the day it is right. So the extractor raises a partial-extraction error carrying whatever it did page through: the data survives, the source is recorded as `partial` , and the tools report it as unread rather than reporting a clean bill of health. Two things, both small. Before writing a batch consumer, `analyze_function` now returns the trigger with `batchSize` and `reportsBatchItemFailures` alongside the event shape, and `get_lambda_overview` carries the same fields for every function. So the assistant knows, before it writes a line, whether the partial-batch response it is about to build will be read or discarded. If it is going to be discarded, the honest answer is either "set `FunctionResponseTypes` first" or "make this handler idempotent," and now that answer is available at coding time. And because the mismatch is graded high, `infrawise check` fails the build on it at the default `--fail-on high` . The mapping-side gap at medium does not — it is a suggestion, not a broken promise. A handler that reports failures nobody reads is a broken promise. `batchItemFailures` ; the event source mapping must set `FunctionResponseTypes: ["ReportBatchItemFailures"]` . One without the other is not half a feature, it is zero.`undefined` and `false` are different answers. A tool that conflates them will eventually be wrong loudly, and after that nobody reads it.Infrawise is open source and exposes this through MCP, so your assistant reads the mapping's real configuration instead of assuming. [GitHub](https://github.com/Sidd27/infrawise) · [npm](https://www.npmjs.com/package/infrawise)