(fix): Fix Typescript Timeouts when Lambda handler returns undefined#661
Merged
Conversation
| promise = Promise.race([callbackProm, asyncProm]); | ||
| } else if (asyncProm === undefined && handler.length < 3) { | ||
| // Handler returned undefined and doesn't take a callback parameter, resolve immediately | ||
| promise = Promise.resolve(undefined); |
Contributor
There was a problem hiding this comment.
Great great find! We definitely need to get some tests in place for this.
Specifically, we need a test that would fail before this change, pass without it. Ideally it would also pass before the update to dogstatsd. Meaning it would have helped us catch this bug before releasing.
duncanista
approved these changes
Jun 12, 2025
purple4reina
approved these changes
Jun 12, 2025
5 tasks
zarirhamza
added a commit
that referenced
this pull request
Jun 11, 2026
Restore the pre-v11.126.0 semantics for the `(event, context) => { ... }` /
`length < 3` / no-return handler shape: when `asyncProm === undefined`, fall
back to `callbackProm` instead of resolving immediately with `undefined`.
PR #661 (v11.126.0) introduced an "eager-resolve on undefined" branch intended
to fix TypeScript-transpiled async handlers whose `return` was lost during
bundling. PR #665 (v12.127.0) refactored that branch and PR #683 (v12.130.0)
added a `looksLikeArtifact` heuristic for handlers that *return* a Server /
EventEmitter, but the `asyncProm === undefined` path was never re-guarded. As
a result every layer from v11.126.0 onwards silently truncates handlers that
return nothing and finish via `context.succeed` / `context.done` /
`context.fail`, most notably `aws-serverless-express@3`'s
`proxy(server, event, context)` with the default `CONTEXT_SUCCEED` resolution
mode.
Symptom: handler returns `undefined` synchronously, wrapper resolves
immediately with `undefined`, the Lambda runtime ships `undefined` back to the
caller and freezes the worker before any deferred work writes to stdout, so
nothing is flushed to CloudWatch.
Tests:
- Replace the test added by PR #661 that codified the regressive "return
undefined -> resolve immediately" behavior.
- Add four regression tests covering the actual contract: a handler with
`length < 3` and no return must wait for `context.succeed` / `context.done` /
`context.fail`, including a reproducer mirroring the aws-serverless-express
`proxy()` shape.
Also tighten `looksLikeArtifact` to require `asyncProm !== null` (the previous
check accepted `null`, which would have thrown on the subsequent `instanceof`
and property-access reads).
5 tasks
zarirhamza
added a commit
that referenced
this pull request
Jun 11, 2026
Restore the pre-v11.126.0 semantics for the `(event, context) => { ... }` /
`length < 3` / no-return handler shape: when `asyncProm === undefined`, fall
back to `callbackProm` instead of resolving immediately with `undefined`.
PR #661 (v11.126.0) introduced an "eager-resolve on undefined" branch intended
to fix TypeScript-transpiled async handlers whose `return` was lost during
bundling. PR #665 (v12.127.0) refactored that branch and PR #683 (v12.130.0)
added a `looksLikeArtifact` heuristic for handlers that *return* a Server /
EventEmitter, but the `asyncProm === undefined` path was never re-guarded. As
a result every layer from v11.126.0 onwards silently truncates handlers that
return nothing and finish via `context.succeed` / `context.done` /
`context.fail`, most notably `aws-serverless-express@3`'s
`proxy(server, event, context)` with the default `CONTEXT_SUCCEED` resolution
mode.
Symptom: handler returns `undefined` synchronously, wrapper resolves
immediately with `undefined`, the Lambda runtime ships `undefined` back to the
caller and freezes the worker before any deferred work writes to stdout, so
nothing is flushed to CloudWatch.
Tests:
- Replace the test added by PR #661 that codified the regressive "return
undefined -> resolve immediately" behavior.
- Add four regression tests covering the actual contract: a handler with
`length < 3` and no return must wait for `context.succeed` / `context.done` /
`context.fail`, including a reproducer mirroring the aws-serverless-express
`proxy()` shape.
zarirhamza
added a commit
that referenced
this pull request
Jun 16, 2026
…#786) Restore the pre-v11.126.0 semantics for the `(event, context) => { ... }` / `length < 3` / no-return handler shape: when `asyncProm === undefined`, fall back to `callbackProm` instead of resolving immediately with `undefined`. PR #661 (v11.126.0) introduced an "eager-resolve on undefined" branch intended to fix TypeScript-transpiled async handlers whose `return` was lost during bundling. PR #665 (v12.127.0) refactored that branch and PR #683 (v12.130.0) added a `looksLikeArtifact` heuristic for handlers that *return* a Server / EventEmitter, but the `asyncProm === undefined` path was never re-guarded. As a result every layer from v11.126.0 onwards silently truncates handlers that return nothing and finish via `context.succeed` / `context.done` / `context.fail`, most notably `aws-serverless-express@3`'s `proxy(server, event, context)` with the default `CONTEXT_SUCCEED` resolution mode. Symptom: handler returns `undefined` synchronously, wrapper resolves immediately with `undefined`, the Lambda runtime ships `undefined` back to the caller and freezes the worker before any deferred work writes to stdout, so nothing is flushed to CloudWatch. Tests: - Replace the test added by PR #661 that codified the regressive "return undefined -> resolve immediately" behavior. - Add four regression tests covering the actual contract: a handler with `length < 3` and no return must wait for `context.succeed` / `context.done` / `context.fail`, including a reproducer mirroring the aws-serverless-express `proxy()` shape.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Originally, when Lambdas return
undefined(this also happens when thereturnstatement is missing), thepromisifiedHandlernever resolved.I'm not exactly sure how, but this bug in combination with my changes in #648 caused timeouts in Typescript apps. Timeouts did not occur before #648.
The fix here is to resolve
promisifiedHandlereven when the handler returns undefined.I'm not exactly sure why this only affects TS but not JS apps.
Motivation
Typescript Lambdas timing out when returning undefined
Testing Guidelines
Manually - no more timeouts
Added unit test -- fails without this change, passes with the change
Additional Notes
Types of Changes
Check all that apply