Why can a batch time out even when every SDK call has a timeout?

Say it in 30 seconds

Say it like this (20-30 seconds)

A per-call timeout is not a budget for the entire invocation. MiniTickets processes up to ten email messages sequentially inside a ten-second Lambda. Each message can perform several AWS calls, with SDK retry and backoff work adding time. I examine whole-batch duration and remaining time, then reduce batch size or bound work before raising the function timeout. Any timeout change must also revisit queue visibility and duplicate handling.

The deeper answer

The email handler checks DynamoDB, sends through SES and records completion. After the batch, it adjusts visibility for failed messages. Repeated slow calls across ten records can exceed the function budget even if each individual call eventually times out.

The email Lambda configures one-second connection and three-second request timeouts, but this does not prove a strict upper bound for every SDK operation or its retries. The ticket entry point additionally sets maxAttempts: 1 and explicit request-timeout failure behavior. Treat those configurations separately.

The email queue visibility is 60 seconds for a ten-second Lambda. AWS recommends at least six times the function timeout, including any configured batching-window allowance. If the invocation times out before returning its partial response, undeleted records can be retried, including records with completed side effects. A proposed remaining-time cutoff would need to report all unprocessed records as failures; that cutoff is not implemented here.

Counter-questions

Why not increase the timeout immediately?

It can conceal slow dependencies and delay retries. Measure the bottleneck and confirm downstream capacity before allowing more work to accumulate.

Does partial failure reporting survive a hard timeout?

No response is returned. The event source mapping cannot use a failure list that the invocation never completed.

Would concurrent processing solve it?

It reduces sequential delay but raises downstream concurrency and duplicate races. Bound parallelism and measure the actual service limits.

Where in MiniTickets

Read the path chapter, select the relevant map piece →, then inspect apps/worker/src/batch.ts → handleBatch. Work through the related case for a diagnostic example.