How I Solved Claude Code Silently Missing the SQS Trigger on My Lambda

I asked Claude Code to add a handler for processOrders, a Lambda wired up to consume from orders-queue and read the matching row out of the Orders DynamoDB table. It wrote one immediately — confidently, in one shot, the way it writes most things.

It also parsed the event body wrong.

The problem: Claude Code didn't know the Lambda had an SQS trigger

processOrders is invoked by orders-queue through an event source mapping — that's not in processOrders's source file, it's in the AWS account. Claude Code, reading only the handler's code, had no way to see that mapping. So it guessed at the event shape instead of knowing it, and reached for event.body — the shape you'd expect from an API Gateway proxy integration, not from SQS. The actual shape for an SQS-triggered Lambda is event.Records[0].body. First message in, first field access, and the handler throws.

That wasn't the only thing invisible from source alone:

• 
  orders-queue has no dead-letter queue. If the handler throws, SQS retries up to maxReceiveCount times and then discards the message — no alert, no queue-depth spike, nothing in the logs pointing at what happened. A failed order just vanishes.


• The Orders table has one partition key (orderId) and zero GSIs. Any lookup by anything else becomes a full table scan the moment the handler ships.

None of that is visible from reading processOrders's current code. It's the state of the AWS account, and an AI assistant reading only source files fills the gap with a plausible guess instead of a fact — starting with which trigger the function even has.

The fix: infrawise's MCP tools in the loop, in order

Here's what the same session looked like once I wired · npm

Key takeaways

• Call analyze_function before writing or reviewing any Lambda handler — it returns the correct trigger event shape, missing IAM permissions, and any DLQ/trigger findings in one call.


• A queue with a live SQS trigger and no DLQ is a high-severity finding for a reason: failed messages are retried up to maxReceiveCount times, then discarded with no record.


• Check isFifo on any queue before writing SendMessage calls — a missing MessageGroupId on a FIFO queue is a runtime error, not a style issue.


• Use get_table_schema with just the tables a handler touches instead of dumping the whole schema into the prompt — it also tells you whether the GSI your query needs already exists.


• None of this requires an LLM to analyze your infrastructure — the graph is deterministic; Claude Code only reads it.