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 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.
The handler that is correct and does nothing Here is a batch consumer.
It is the shape you get if you read the AWS docs and follow them.
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 on the mapping does not contain , 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.
Why nobody catches this in review Read that handler again with a critical eye.
There is nothing wrong with it.
It builds the array correctly, it uses 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 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.
Two ends of the same contract, two different findings 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. looks for an , , or trigger with a batch size above 1 and no .
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. fires when the code builds a 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 , 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. rides on the response that trigger extraction already pages through, so the whole check is a field carried forward plus two analyzers.
The rule that keeps it honest One detail mattered more than the analyzers themselves.
Both checks fire onl