Your retry logic is correct and does nothing

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. 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.

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, 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 · npm