Partial batch failures: the handler is fine, the mapping decides

The grading is the part worth stealing. A mapping with a batch size above 1 and no ReportBatchItemFailures is scored medium in the author's scanner, because the handler may genuinely not need per-record reporting, and a batch of one is skipped outright since it has nothing to partially fail ^[10]. The mismatch, where the code builds a batchItemFailures array and the mapping has the setting off, is scored high ^[11]. The analyzer description is blunt about the reason: "The code reads as correct and its unit tests pass; only the mapping tells the truth" ^[12]. The distinction being drawn is between an absence and an active false belief ^[16]. Somebody wrote that array on purpose, and whatever they concluded about idempotency downstream was concluded on the assumption that the nine good records would be deleted.

That assumption fails quietly. One throwing record sends the whole batch back, the nine that already ran to completion included, and it keeps replaying until the queue's retry limit ^[5]. Nine of ten records in each replay are re-executions, which puts 90 percent of the retried work in the duplicate column ^[1]. If the handler is not idempotent, the author's phrasing is fair: double-charged customers rather than a log line ^[6]. A unit test that feeds ten records and asserts one entry in the failure array passes the entire time ^[7].

Neither side of the check is expensive, which is the uncomfortable bit. Both scanners match a name: ts-morph on a property or shorthand property called batchItemFailures, the Python scanner on the same dict key, with no control-flow tracing to a return statement, on the reasoning that an array by that name has no other purpose in a Lambda handler ^[13]. The infrastructure side is close to free, because FunctionResponseTypes already arrives on the ListEventSourceMappings response that trigger extraction pages through anyway ^[14]. So this class of defect does not survive because it is hard to find. It survives because the two halves are never in the same place: a Terraform module in another repo, a CDK stack another team owns, or a checkbox someone clicked in a console eighteen months ago, none of which your editor or test suite can see ^[8].

One design choice deserves reading closely. Both checks fire only on an explicit false ^[15]. The write-up's explanation of that rule breaks off mid-comment in the material supplied, so how an unreadable or absent mapping is treated is not stated. Either way, a finding means the two halves disagree, and silence cannot be read as agreement.

Then the assistant path, which is how the high-severity direction gets manufactured at volume. Asked to add partial batch failure handling to a consumer, an assistant writes exactly the correct-looking handler and reports the job done, not hallucinating, just writing the only half it can see ^[9]. The cheap half to generate is the half that is graded high when it is wrong. On that basis the mismatch population should grow faster than the plain-absence population, and it will grow in repositories where the mapping is owned by someone who was never in the pull request.