fix: stop a malformed SQS body from poisoning the whole batch

[vegardx]

Problem

JSON.parse(body) runs in the record loop at the top of scaleUpHandler, outside the try/catch further down. An unparseable message body therefore throws straight out of the handler.

Lambda treats a thrown exception as a complete batch failure, so nothing is deleted and the entire batch returns to the queue after the visibility timeout. The body is malformed deterministically, so every redelivery reproduces the same SyntaxError. scaleUp is never reached, which means valid messages batched alongside the malformed one are never processed either — they are blocked as collateral damage.

Two things make it worse:

• ReportBatchItemFailures disables Lambda's scale-down of message polling when invocations fail, so the usual concurrency backoff does not apply.
• redrive_build_queue defaults to enabled = false, so there is no maxReceiveCount cap. The only backstop is job_queue_retention_in_seconds, default 24h.

Verified empirically against main: a batch of two valid records plus one malformed one rejects with SyntaxError and scaleUp is called zero times.

Change

Parse each record defensively. A malformed body is logged and reported as an individual batch item failure; the rest of the batch proceeds to scaleUp as normal.

The malformed message then exhausts maxReceiveCount on its own rather than taking the batch with it. It cannot be acknowledged and discarded through the partial-failure mechanism — reporting it is the only way to single it out — so with the default configuration it expires by retention rather than moving to a DLQ. Operators who want these captured should enable redrive_build_queue.

Tests

Four tests covering: the invocation no longer fails, only the malformed message is reported, valid messages still reach scaleUp, and malformed and rejected messages combine correctly. All four fail against the current implementation.

Note on scope

This is distinct from #5129. That PR addresses the catch block, where a non-ScaleError returns an empty batchItemFailures — which AWS treats as complete success, so the batch is deleted. Opposite failure mode, different path, and worth keeping separate. I originally conflated the two in a comment on #5129 and have corrected it there.

Touches the same file as #5129, so whichever lands second will need a trivial rebase.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[edersonbrilhante]

Thanks for this PR