Skip to content

feat(standard-server): AWS Lambda Adapter #534

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 22 commits into from
May 28, 2025
Merged

Conversation

unnoq
Copy link
Owner

@unnoq unnoq commented May 22, 2025

Summary by CodeRabbit

  • New Features

    • Introduced AWS Lambda adapters for oRPC, enabling seamless integration with AWS Lambda for both RPC and OpenAPI endpoints.
    • Added comprehensive support for Lambda event and response handling, including streaming, headers, body conversion, and abort signal integration.
    • Provided example usage and updated documentation for deploying oRPC endpoints on AWS Lambda.
    • Added utilities for converting Lambda event bodies, headers, URLs, and requests to standardized formats and vice versa.
    • Enabled strict HTTP method enforcement in RPC handler with default GET method checking.
  • Bug Fixes

    • None.
  • Documentation

    • Updated and expanded documentation to cover AWS Lambda integration, usage examples, and adapter details.
  • Tests

    • Added extensive test coverage for Lambda adapters, including body parsing and serialization, headers conversion, event streaming, request/response handling, abort signals, and type compatibility.
  • Chores

    • Added configuration, metadata, and project references for the new AWS Lambda adapter package.
    • Added new package for standard server AWS Lambda adapter with build and type scripts.

Copy link

vercel bot commented May 22, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
orpc ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 28, 2025 2:06am

Copy link

coderabbitai bot commented May 22, 2025

Walkthrough

This change introduces first-class AWS Lambda support to the oRPC ecosystem. It adds new AWS Lambda adapters for both the server and OpenAPI packages, implements Lambda-specific handler classes, and provides bidirectional conversion utilities for Lambda events, headers, bodies, and streaming responses. Comprehensive documentation, tests, and TypeScript project configuration updates are included.

Changes

File(s) Change Summary
apps/content/docs/adapters/http.md Updated docs: Added AWS Lambda adapter, usage example with experimental_RPCHandler, streaming response handling, and route prefix handling notes.
packages/server/package.json, packages/openapi/package.json Added AWS Lambda adapter exports and dependencies; updated module resolution and export maps for Lambda support.
packages/server/src/adapters/aws-lambda/handler.ts, rpc-handler.ts, index.ts Added AwsLambdaHandler class adapting standard handlers for Lambda; added experimental_RPCHandler extending it with strict GET method plugin; added index re-exports.
packages/server/src/adapters/aws-lambda/rpc-handler.test.ts Added tests for experimental_RPCHandler covering route matching, method validation, and response sending behavior.
packages/server/tsconfig.json, tsconfig.json Added TypeScript project references for the new Lambda server package.
packages/openapi/src/adapters/aws-lambda/openapi-handler.ts, index.ts Added experimental_OpenAPIHandler class extending AwsLambdaHandler with OpenAPI support; added index re-export.
packages/openapi/src/adapters/aws-lambda/openapi-handler.test.ts Added tests for OpenAPIHandler covering route matching and response logic.
packages/standard-server-aws-lambda/package.json, tsconfig.json, .gitignore, README.md New package declared and configured for AWS Lambda standard server adapter with documentation and ignore rules.
packages/standard-server-aws-lambda/src/body.ts, headers.ts, event-iterator.ts, request.ts, response.ts, signal.ts, types.ts, url.ts, index.ts Implemented Lambda-specific utilities: conversion between Lambda event bodies and standard bodies, header conversions, event stream iterator and stream, lazy request creation, response sending with streaming support, abort signal from writable streams, type definitions, URL conversion, and consolidated exports.
packages/standard-server-aws-lambda/src/body.test.ts, headers.test.ts, event-iterator.test.ts, request.test.ts, response.test.ts, signal.test.ts, types.test-d.ts, url.test.ts Added comprehensive unit tests for Lambda utilities covering body and header conversions, event streaming, lazy request creation, response sending, abort signal handling, type compatibility, and URL conversion.

Sequence Diagram(s)

sequenceDiagram
    participant API Gateway
    participant AWS Lambda
    participant oRPC Lambda Handler
    participant Standard Handler
    participant Response Stream

    API Gateway->>AWS Lambda: Invoke with APIGatewayProxyEventV2
    AWS Lambda->>oRPC Lambda Handler: Pass event, responseStream
    oRPC Lambda Handler->>Standard Handler: Convert event to StandardLazyRequest, handle()
    Standard Handler-->>oRPC Lambda Handler: StandardResponse (or no match)
    alt Route matched
        oRPC Lambda Handler->>Response Stream: sendStandardResponse(StandardResponse)
        Response Stream-->>API Gateway: Streamed response
    else No route match
        oRPC Lambda Handler-->>AWS Lambda: Return 404 or { matched: false }
    end
Loading

Possibly related PRs

  • unnoq/orpc#183: Adds configurable event-source ping interval options to keep EventSource connections alive. This is related as both PRs enhance RPCHandler/event streaming logic, and the new AWS Lambda RPCHandler internally uses event streaming where ping interval options are relevant.

Poem

🐇
In the cloud where Lambdas leap,
oRPC now runs so deep.
Headers, bodies, streams—oh my!
Adapters soar, requests now fly.
With tests and docs, the code is tight,
Lambda support shines bright at night!
☁️✨


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 68542a8 and 99afd6e.

📒 Files selected for processing (4)
  • packages/standard-server-aws-lambda/src/event-iterator.test.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/response.test.ts (1 hunks)
  • packages/standard-server-fetch/src/event-iterator.test.ts (1 hunks)
  • packages/standard-server-node/src/event-iterator.test.ts (1 hunks)
✅ Files skipped from review due to trivial changes (2)
  • packages/standard-server-node/src/event-iterator.test.ts
  • packages/standard-server-fetch/src/event-iterator.test.ts
🚧 Files skipped from review as they are similar to previous changes (2)
  • packages/standard-server-aws-lambda/src/response.test.ts
  • packages/standard-server-aws-lambda/src/event-iterator.test.ts
⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: publish-commit
  • GitHub Check: lint
✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

codecov bot commented May 22, 2025

Codecov Report

Attention: Patch coverage is 97.41379% with 9 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
packages/standard-server-aws-lambda/src/index.ts 11.11% 8 Missing ⚠️
packages/openapi/src/adapters/aws-lambda/index.ts 0.00% 0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

Copy link

pkg-pr-new bot commented May 27, 2025

More templates

@orpc/arktype

npm i https://pkg.pr.new/@orpc/arktype@534

@orpc/client

npm i https://pkg.pr.new/@orpc/client@534

@orpc/contract

npm i https://pkg.pr.new/@orpc/contract@534

@orpc/hey-api

npm i https://pkg.pr.new/@orpc/hey-api@534

@orpc/openapi

npm i https://pkg.pr.new/@orpc/openapi@534

@orpc/openapi-client

npm i https://pkg.pr.new/@orpc/openapi-client@534

@orpc/nest

npm i https://pkg.pr.new/@orpc/nest@534

@orpc/react

npm i https://pkg.pr.new/@orpc/react@534

@orpc/react-query

npm i https://pkg.pr.new/@orpc/react-query@534

@orpc/server

npm i https://pkg.pr.new/@orpc/server@534

@orpc/shared

npm i https://pkg.pr.new/@orpc/shared@534

@orpc/solid-query

npm i https://pkg.pr.new/@orpc/solid-query@534

@orpc/standard-server

npm i https://pkg.pr.new/@orpc/standard-server@534

@orpc/standard-server-aws-lambda

npm i https://pkg.pr.new/@orpc/standard-server-aws-lambda@534

@orpc/standard-server-fetch

npm i https://pkg.pr.new/@orpc/standard-server-fetch@534

@orpc/standard-server-node

npm i https://pkg.pr.new/@orpc/standard-server-node@534

@orpc/standard-server-peer

npm i https://pkg.pr.new/@orpc/standard-server-peer@534

@orpc/svelte-query

npm i https://pkg.pr.new/@orpc/svelte-query@534

@orpc/tanstack-query

npm i https://pkg.pr.new/@orpc/tanstack-query@534

@orpc/valibot

npm i https://pkg.pr.new/@orpc/valibot@534

@orpc/vue-colada

npm i https://pkg.pr.new/@orpc/vue-colada@534

@orpc/vue-query

npm i https://pkg.pr.new/@orpc/vue-query@534

@orpc/zod

npm i https://pkg.pr.new/@orpc/zod@534

commit: 99afd6e

@unnoq unnoq marked this pull request as ready for review May 27, 2025 12:28
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 8

🧹 Nitpick comments (10)
packages/standard-server-aws-lambda/.gitignore (2)

1-5: Be cautious with the .* pattern for hidden files
The .* entry will ignore all dotfiles (and directories) at this package’s root, which may inadvertently hide important config folders if they ever appear here. Consider scoping it to the root only (e.g., /.*) or confirm that ignoring every hidden file is intentional.


24-26: Optional: Narrow the *.local pattern
Using *.local will ignore all files ending in .local. If the goal is only to exclude environment overrides (e.g., .env.local), consider specifying that file explicitly.

packages/standard-server-aws-lambda/src/signal.ts (1)

3-17: Well-implemented AbortSignal creation with proper error handling.

The implementation correctly handles stream lifecycle events and provides appropriate error propagation. The use of once listeners ensures proper cleanup, and the check for writableFinished properly detects premature stream closure.

Consider adding JSDoc documentation for better API clarity:

+/**
+ * Creates an AbortSignal that aborts when the provided writable stream
+ * encounters an error or closes prematurely.
+ * 
+ * @param responseStream - The writable stream to monitor
+ * @returns AbortSignal that aborts on stream error or premature closure
+ */
 export function toAbortSignal(
   responseStream: Stream.Writable,
 ): AbortSignal {
packages/standard-server-aws-lambda/src/headers.test.ts (1)

3-16: Verify the test logic for handling invalid set-cookie header.

The test passes a 'set-cookie': 'invalid' in the headers object, but based on the toStandardHeaders implementation, this will be overwritten by the cookies array. The test expects the cookies array to take precedence, which appears correct.

However, consider adding a test case that verifies the behavior when cookies array is undefined to ensure complete coverage.

Consider adding this additional test case for better coverage:

+it('toStandardHeaders with undefined cookies', () => {
+  expect(toStandardHeaders({
+    'content-type': 'application/json',
+    'set-cookie': 'from-headers',
+  }, undefined)).toEqual({
+    'content-type': 'application/json',
+    'set-cookie': undefined,
+  })
+})
packages/openapi/src/adapters/aws-lambda/openapi-handler.test.ts (1)

26-27: Use more realistic mock objects.

The mock event and responseStream objects are overly simplified ({ req: true } and { res: true }). While this works for unit testing, using more realistic mock objects would improve test reliability and catch potential type issues.

Consider using more realistic mock objects:

-  const event: any = { req: true }
-  const responseStream: any = { res: true }
+  const event: any = {
+    version: '2.0',
+    routeKey: '$default',
+    rawPath: '/api/v1/ping',
+    rawQueryString: 'key=value',
+    requestContext: {
+      domainName: 'example.com',
+      http: {
+        method: 'GET',
+        path: '/api/v1/ping',
+        protocol: 'HTTP/1.1'
+      }
+    },
+    headers: {},
+    isBase64Encoded: false
+  }
+  const responseStream: any = {
+    write: vi.fn(),
+    end: vi.fn(),
+    on: vi.fn(),
+    once: vi.fn()
+  }
packages/server/src/adapters/aws-lambda/rpc-handler.ts (1)

25-33: Consider defensive copying to prevent options mutation.

The current implementation directly mutates the options.plugins array, which could cause issues if the same options object is reused across multiple handler instances.

Consider creating a shallow copy of options before mutation:

  constructor(router: Router<any, T>, options: NoInfer<RPCHandlerOptions<T>> = {}) {
+   const safeOptions = { ...options }
    if (options.strictGetMethodPluginEnabled ?? true) {
-     options.plugins ??= []
-     options.plugins.push(new StrictGetMethodPlugin())
+     safeOptions.plugins = [...(options.plugins ?? []), new StrictGetMethodPlugin()]
    }

-   super(new StandardRPCHandler(router, options), options)
+   super(new StandardRPCHandler(router, safeOptions), safeOptions)
  }
packages/standard-server-aws-lambda/src/response.ts (2)

7-7: Consider adding JSDoc documentation for the options interface.

While the interface extension is clean, it would benefit from documentation explaining its purpose in the AWS Lambda context.

+/**
+ * Options for sending standard responses in AWS Lambda environment.
+ * Extends ToLambdaBodyOptions to include body conversion settings.
+ */
 export interface SendStandardResponseOptions extends ToLambdaBodyOptions {}

31-34: Improve string body handling with proper encoding.

The current implementation writes the string directly without specifying encoding, which could lead to encoding issues.

 else if (typeof body === 'string') {
-  responseStream.write(body)
+  responseStream.write(body, 'utf8')
   responseStream.end()
 }
packages/standard-server-aws-lambda/src/types.ts (1)

1-1: Consider adding more specific attribution and version information.

The comment is helpful but could be more specific about which version of aws-lambda types these are based on.

-// this is mainly copied from aws-lambda
+// Type definitions based on @types/aws-lambda APIGatewayProxyEventV2
+// See: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/aws-lambda/index.d.ts
packages/standard-server-aws-lambda/src/event-iterator.test.ts (1)

41-42: Fix typo in test description.

There's a typo in the test description.

-  it('without dont event', async () => {
+  it('without done event', async () => {
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5a89db9 and 68542a8.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (33)
  • apps/content/docs/adapters/http.md (2 hunks)
  • packages/openapi/package.json (2 hunks)
  • packages/openapi/src/adapters/aws-lambda/index.ts (1 hunks)
  • packages/openapi/src/adapters/aws-lambda/openapi-handler.test.ts (1 hunks)
  • packages/openapi/src/adapters/aws-lambda/openapi-handler.ts (1 hunks)
  • packages/server/package.json (3 hunks)
  • packages/server/src/adapters/aws-lambda/handler.ts (1 hunks)
  • packages/server/src/adapters/aws-lambda/index.ts (1 hunks)
  • packages/server/src/adapters/aws-lambda/rpc-handler.test.ts (1 hunks)
  • packages/server/src/adapters/aws-lambda/rpc-handler.ts (1 hunks)
  • packages/server/tsconfig.json (1 hunks)
  • packages/standard-server-aws-lambda/.gitignore (1 hunks)
  • packages/standard-server-aws-lambda/README.md (1 hunks)
  • packages/standard-server-aws-lambda/package.json (1 hunks)
  • packages/standard-server-aws-lambda/src/body.test.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/body.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/event-iterator.test.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/event-iterator.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/headers.test.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/headers.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/index.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/request.test.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/request.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/response.test.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/response.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/signal.test.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/signal.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/types.test-d.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/types.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/url.test.ts (1 hunks)
  • packages/standard-server-aws-lambda/src/url.ts (1 hunks)
  • packages/standard-server-aws-lambda/tsconfig.json (1 hunks)
  • tsconfig.json (1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (13)
packages/server/src/adapters/aws-lambda/handler.ts (8)
packages/standard-server-aws-lambda/src/response.ts (2)
  • SendStandardResponseOptions (7-7)
  • sendStandardResponse (9-47)
packages/server/src/context.ts (1)
  • Context (1-1)
packages/server/src/adapters/standard/handler.ts (1)
  • StandardHandler (50-145)
packages/standard-server-aws-lambda/src/types.ts (1)
  • APIGatewayProxyEventV2 (19-39)
packages/standard-server-aws-lambda/src/index.ts (1)
  • ResponseStream (12-12)
packages/shared/src/args.ts (2)
  • MaybeOptionalOptions (1-3)
  • resolveMaybeOptionalOptions (5-7)
packages/server/src/adapters/standard/utils.ts (2)
  • FriendlyStandardHandleOptions (4-6)
  • resolveFriendlyStandardHandleOptions (8-13)
packages/standard-server-aws-lambda/src/request.ts (1)
  • toStandardLazyRequest (10-25)
packages/standard-server-aws-lambda/src/signal.test.ts (1)
packages/standard-server-aws-lambda/src/signal.ts (1)
  • toAbortSignal (3-17)
packages/standard-server-aws-lambda/src/headers.test.ts (2)
packages/standard-server-aws-lambda/src/headers.ts (2)
  • toStandardHeaders (6-14)
  • toLambdaHeaders (16-36)
packages/standard-server-aws-lambda/src/request.ts (2)
  • headers (14-18)
  • headers (19-21)
packages/server/src/adapters/aws-lambda/rpc-handler.ts (5)
packages/server/src/context.ts (1)
  • Context (1-1)
packages/server/src/adapters/aws-lambda/handler.ts (2)
  • AwsLambdaHandlerOptions (10-12)
  • AwsLambdaHandler (16-44)
packages/server/src/adapters/standard/rpc-handler.ts (2)
  • StandardRPCHandlerOptions (10-11)
  • StandardRPCHandler (13-22)
packages/server/src/router.ts (1)
  • Router (12-17)
packages/server/src/plugins/strict-get-method.ts (1)
  • StrictGetMethodPlugin (24-63)
packages/standard-server-aws-lambda/src/body.ts (6)
packages/standard-server-aws-lambda/src/types.ts (1)
  • APIGatewayProxyEventV2 (19-39)
packages/standard-server/src/types.ts (2)
  • StandardBody (5-11)
  • StandardHeaders (1-3)
packages/standard-server/src/utils.ts (3)
  • getFilenameFromContentDisposition (15-26)
  • flattenHeader (51-61)
  • generateContentDisposition (4-13)
packages/shared/src/json.ts (2)
  • parseEmptyableJSON (1-7)
  • stringifyJSON (9-12)
packages/standard-server-aws-lambda/src/event-iterator.ts (3)
  • toEventIterator (5-62)
  • ToEventStreamOptions (64-85)
  • toEventStream (87-156)
packages/shared/src/iterator.ts (1)
  • isAsyncIteratorObject (3-9)
packages/standard-server-aws-lambda/src/headers.ts (5)
packages/standard-server-aws-lambda/src/request.ts (2)
  • headers (14-18)
  • headers (19-21)
packages/standard-server-aws-lambda/src/types.ts (1)
  • APIGatewayProxyEventHeaders (3-5)
packages/standard-server/src/types.ts (1)
  • StandardHeaders (1-3)
packages/shared/src/array.ts (1)
  • toArray (1-3)
packages/standard-server/src/utils.ts (1)
  • flattenHeader (51-61)
packages/openapi/src/adapters/aws-lambda/openapi-handler.ts (4)
packages/server/src/context.ts (1)
  • Context (1-1)
packages/server/src/adapters/aws-lambda/handler.ts (2)
  • AwsLambdaHandler (16-44)
  • AwsLambdaHandlerOptions (10-12)
packages/server/src/router.ts (1)
  • Router (12-17)
packages/openapi/src/adapters/standard/openapi-handler.ts (2)
  • StandardOpenAPIHandlerOptions (9-10)
  • StandardOpenAPIHandler (12-22)
packages/standard-server-aws-lambda/src/request.test.ts (3)
packages/standard-server-aws-lambda/src/types.ts (1)
  • APIGatewayProxyEventV2 (19-39)
packages/standard-server-aws-lambda/src/request.ts (1)
  • toStandardLazyRequest (10-25)
packages/shared/src/iterator.ts (1)
  • isAsyncIteratorObject (3-9)
packages/standard-server-aws-lambda/src/url.ts (1)
packages/standard-server-aws-lambda/src/types.ts (1)
  • APIGatewayProxyEventV2 (19-39)
packages/standard-server-aws-lambda/src/types.test-d.ts (1)
packages/standard-server-aws-lambda/src/types.ts (1)
  • APIGatewayProxyEventV2 (19-39)
packages/standard-server-aws-lambda/src/url.test.ts (1)
packages/standard-server-aws-lambda/src/url.ts (1)
  • toStandardUrl (3-5)
packages/standard-server-aws-lambda/src/event-iterator.ts (5)
packages/standard-server/src/event-iterator/decoder.ts (1)
  • EventDecoderStream (92-112)
packages/shared/src/iterator.ts (1)
  • createAsyncIteratorObject (15-82)
packages/shared/src/json.ts (2)
  • parseEmptyableJSON (1-7)
  • stringifyJSON (9-12)
packages/shared/src/object.ts (1)
  • isTypescriptObject (44-46)
packages/standard-server/src/event-iterator/encoder.ts (1)
  • encodeEventMessage (52-79)
packages/standard-server-aws-lambda/src/request.ts (7)
packages/standard-server-aws-lambda/src/types.ts (1)
  • APIGatewayProxyEventV2 (19-39)
packages/standard-server/src/types.ts (1)
  • StandardLazyRequest (26-32)
packages/standard-server-aws-lambda/src/url.ts (1)
  • toStandardUrl (3-5)
packages/standard-server-aws-lambda/src/headers.ts (1)
  • toStandardHeaders (6-14)
packages/standard-server-aws-lambda/src/signal.ts (1)
  • toAbortSignal (3-17)
packages/shared/src/function.ts (1)
  • once (3-16)
packages/standard-server-aws-lambda/src/body.ts (1)
  • toStandardBody (10-42)
🪛 GitHub Check: codecov/patch
packages/standard-server-aws-lambda/src/index.ts

[warning] 3-10: packages/standard-server-aws-lambda/src/index.ts#L3-L10
Added lines #L3 - L10 were not covered by tests

🪛 LanguageTool
packages/standard-server-aws-lambda/README.md

[misspelling] ~33-~33: Possible spelling mistakes found.
Context: ...tack Query (React, Vue, Solid, Svelte), Pinia Colada, and more. - 🚀 Server Actions: Ful...

(EN_MULTITOKEN_SPELLING_TWO)


[style] ~51-~51: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... your API or implement API contract. - [@orpc/client](https://www.npmjs.com/package/@...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~52-~52: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... API on the client with type-safety. - [@orpc/nest](https://www.npmjs.com/package/@or...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~53-~53: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...: Deeply integrate oRPC with NestJS. - [@orpc/react](https://www.npmjs.com/package/@o...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~54-~54: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...with React and React Server Actions. - [@orpc/react-query](https://www.npmjs.com/pack...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~55-~55: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...test/docs/framework/react/overview). - [@orpc/vue-query](https://www.npmjs.com/packag...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~56-~56: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...latest/docs/framework/vue/overview). - [@orpc/solid-query](https://www.npmjs.com/pack...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~57-~57: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...test/docs/framework/solid/overview). - [@orpc/svelte-query](https://www.npmjs.com/pac...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~58-~58: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...est/docs/framework/svelte/overview). - [@orpc/vue-colada](https://www.npmjs.com/packa...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[misspelling] ~58-~58: Possible spelling mistakes found.
Context: ...ge/@orpc/vue-colada): Integration with Pinia Colada. - [@or...

(EN_MULTITOKEN_SPELLING_TWO)


[style] ~59-~59: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ada](https://pinia-colada.esm.dev/). - [@orpc/openapi](https://www.npmjs.com/package/...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~60-~60: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...I specs and handle OpenAPI requests. - [@orpc/zod](https://www.npmjs.com/package/@orp...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~61-~61: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...tps://zod.dev/) doesn't support yet. - [@orpc/valibot](https://www.npmjs.com/package/...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~62-~62: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...rom Valibot. - [@orpc/arktype](https://www.npmjs.com/package/...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)

🪛 Biome (1.9.4)
packages/standard-server-aws-lambda/src/event-iterator.ts

[error] 7-7: void is confusing inside a union type.

Unsafe fix: Use undefined instead.

(lint/suspicious/noConfusingVoidType)


[error] 7-7: void is confusing inside a union type.

Unsafe fix: Use undefined instead.

(lint/suspicious/noConfusingVoidType)


[error] 7-7: void is confusing inside a union type.

Unsafe fix: Use undefined instead.

(lint/suspicious/noConfusingVoidType)


[error] 7-7: void is confusing inside a union type.

Unsafe fix: Use undefined instead.

(lint/suspicious/noConfusingVoidType)


[error] 88-88: void is confusing inside a union type.

Unsafe fix: Use undefined instead.

(lint/suspicious/noConfusingVoidType)


[error] 88-88: void is confusing inside a union type.

Unsafe fix: Use undefined instead.

(lint/suspicious/noConfusingVoidType)

🔇 Additional comments (62)
packages/standard-server-aws-lambda/.gitignore (2)

6-15: Generated folder ignores look comprehensive
The listed directories (logs/, node_modules/, out/, dist/, dist-ssr/, build/, coverage/, temp/) cover standard transient artifacts for this package. No issues found.


16-23: Generated file ignores are appropriate
Ignoring log files, build artifacts (*.tsbuildinfo, *.vitest-temp.json), and timestamped Vite/Vitest configs aligns with expected outputs.

tsconfig.json (1)

19-19: Include new AWS Lambda adapter in project references
Integrating standard-server-aws-lambda into the root tsconfig ensures the new package is part of the monorepo build. Confirm the path matches the actual folder and that the package’s own tsconfig enables project references (composite: true).

packages/server/tsconfig.json (1)

9-9: Add AWS Lambda reference to server package
Including "../standard-server-aws-lambda" here allows the server package to compile against the Lambda adapter utilities. Ensure packages/server/package.json also lists @orpc/standard-server-aws-lambda as a dependency.

packages/openapi/src/adapters/aws-lambda/index.ts (1)

1-1: Expose the new OpenAPI AWS Lambda handler
Re-exporting from ./openapi-handler makes the experimental_OpenAPIHandler available through the package entrypoint. Verify that openapi-handler.ts exports the correct handler class.

packages/standard-server-aws-lambda/src/types.test-d.ts (1)

1-6: Verify AWS Lambda event type compatibility
This test correctly asserts that awslambda.APIGatewayProxyEventV2 extends the local APIGatewayProxyEventV2. Ensure Vitest’s expectTypeOf is available and that @types/aws-lambda is a dev dependency.

packages/server/src/adapters/aws-lambda/index.ts (1)

1-2: Consolidate AWS Lambda handler exports
Re-exporting both handler and rpc-handler provides a unified import surface. Looks correct; update documentation and package exports to cover this new entrypoint.

packages/standard-server-aws-lambda/tsconfig.json (1)

1-19: Well-configured TypeScript setup for the AWS Lambda package.

The configuration properly extends the base library configuration, uses appropriate ES2022 features for AWS Lambda environments, and includes sensible exclusion patterns for test files. The project reference to the shared package is correctly configured.

packages/standard-server-aws-lambda/src/index.ts (1)

1-12: LGTM! Clean and well-structured package entry point.

The index file properly consolidates all package exports and provides a useful ResponseStream type alias that simplifies the interface for consumers. The type import syntax is correct and the re-exports follow standard patterns.

🧰 Tools
🪛 GitHub Check: codecov/patch

[warning] 3-10: packages/standard-server-aws-lambda/src/index.ts#L3-L10
Added lines #L3 - L10 were not covered by tests

packages/standard-server-aws-lambda/src/request.ts (1)

10-25: Excellent lazy evaluation implementation!

The toStandardLazyRequest function demonstrates well-thought-out lazy evaluation patterns:

  1. Headers lazy evaluation: The getter/setter pattern correctly computes headers on first access and caches the result using Object.defineProperty
  2. Body lazy evaluation: Proper use of the once utility ensures the body is computed only when needed and cached for subsequent calls
  3. Clean integration: All utility functions are properly leveraged for URL, headers, signal, and body conversion

The implementation efficiently handles AWS Lambda event conversion while maintaining performance through lazy evaluation.

packages/standard-server-aws-lambda/README.md (1)

1-78: Comprehensive and well-structured documentation.

The README follows the standard oRPC package format and provides excellent coverage of features, integrations, and usage. The content is informative and professionally presented.

Note: The static analysis style warnings about repetitive sentence beginnings in the packages list and "misspellings" of framework names like "Pinia Colada" and "Svelte" are acceptable in this context - the structured list format is appropriate and the flagged terms are proper names.

🧰 Tools
🪛 LanguageTool

[misspelling] ~33-~33: Possible spelling mistakes found.
Context: ...tack Query (React, Vue, Solid, Svelte), Pinia Colada, and more. - 🚀 Server Actions: Ful...

(EN_MULTITOKEN_SPELLING_TWO)


[style] ~51-~51: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... your API or implement API contract. - [@orpc/client](https://www.npmjs.com/package/@...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~52-~52: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... API on the client with type-safety. - [@orpc/nest](https://www.npmjs.com/package/@or...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~53-~53: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...: Deeply integrate oRPC with NestJS. - [@orpc/react](https://www.npmjs.com/package/@o...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~54-~54: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...with React and React Server Actions. - [@orpc/react-query](https://www.npmjs.com/pack...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~55-~55: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...test/docs/framework/react/overview). - [@orpc/vue-query](https://www.npmjs.com/packag...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~56-~56: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...latest/docs/framework/vue/overview). - [@orpc/solid-query](https://www.npmjs.com/pack...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~57-~57: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...test/docs/framework/solid/overview). - [@orpc/svelte-query](https://www.npmjs.com/pac...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~58-~58: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...est/docs/framework/svelte/overview). - [@orpc/vue-colada](https://www.npmjs.com/packa...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[misspelling] ~58-~58: Possible spelling mistakes found.
Context: ...ge/@orpc/vue-colada): Integration with Pinia Colada. - [@or...

(EN_MULTITOKEN_SPELLING_TWO)


[style] ~59-~59: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ada](https://pinia-colada.esm.dev/). - [@orpc/openapi](https://www.npmjs.com/package/...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~60-~60: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...I specs and handle OpenAPI requests. - [@orpc/zod](https://www.npmjs.com/package/@orp...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~61-~61: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...tps://zod.dev/) doesn't support yet. - [@orpc/valibot](https://www.npmjs.com/package/...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~62-~62: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...rom Valibot. - [@orpc/arktype](https://www.npmjs.com/package/...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)

packages/openapi/src/adapters/aws-lambda/openapi-handler.ts (1)

1-17: Clean composition pattern with excellent documentation.

The experimental_OpenAPIHandler class demonstrates a well-designed composition pattern:

  1. Proper inheritance: Extends AwsLambdaHandler<T> to leverage AWS Lambda adapter functionality
  2. Type-safe options: Correctly combines StandardOpenAPIHandlerOptions<T> and AwsLambdaHandlerOptions using intersection types
  3. Clean delegation: Creates StandardOpenAPIHandler internally and passes it to the parent constructor
  4. Clear naming: The experimental_ prefix appropriately indicates this is new functionality
  5. Good documentation: JSDoc comments include relevant links to OpenAPI and HTTP adapter documentation

The implementation efficiently bridges OpenAPI functionality with AWS Lambda support.

packages/standard-server-aws-lambda/src/headers.test.ts (1)

18-32: Test logic is correct for bidirectional header conversion.

The test correctly verifies:

  • Array headers are flattened with comma separation
  • set-cookie headers are extracted to separate cookies array
  • Undefined headers are filtered out
  • Regular headers are preserved

The expected outputs match the toLambdaHeaders implementation from the relevant code snippets.

packages/openapi/package.json (1)

42-47: Export configuration looks consistent with existing adapters.

The AWS Lambda adapter export follows the same pattern as other adapters (node, fetch, standard) with proper TypeScript types and ESM module configuration.

packages/standard-server-aws-lambda/package.json (1)

1-43: Package configuration looks well-structured for a new AWS Lambda utilities package.

The package.json follows standard conventions with proper:

  • Metadata (name, version, license, repository)
  • ES module configuration
  • Export mappings for TypeScript and built files
  • Workspace dependencies on shared and standard-server packages
  • AWS Lambda types for development

The dependencies are appropriate for a utility package that provides AWS Lambda integration.

packages/server/package.json (3)

43-47: AWS Lambda adapter export is properly configured.

The export configuration follows the same pattern as other adapters with correct TypeScript types and ESM module paths.


81-81: Export path is consistent with publishConfig.

The development export correctly points to the TypeScript source file, maintaining consistency with other adapters.


113-113: Dependency on standard-server-aws-lambda is correctly added.

The workspace dependency is properly added, enabling the server package to use the AWS Lambda utilities for its adapter implementation.

packages/openapi/src/adapters/aws-lambda/openapi-handler.test.ts (3)

40-59: Excellent test coverage for the matched route scenario.

The test correctly verifies that:

  • The handler returns { matched: true }
  • toStandardLazyRequest is called with the correct parameters
  • sendStandardResponse is called with the expected response structure

The assertion on the response body structure confirms the handler correctly processes the input and returns the expected output format.


61-79: Good test coverage for the mismatch scenario.

The test properly verifies that when a route doesn't match:

  • The handler returns { matched: false, response: undefined }
  • toStandardLazyRequest is still called (as expected for request processing)
  • sendStandardResponse is not called (avoiding unnecessary response processing)

1-8:

✅ Verification successful

Verify import and mocking setup.

The mocking setup looks correct, but there's a potential issue with the import structure and module resolution.

Let me verify that the mocked functions are correctly imported and the module structure is as expected:


🏁 Script executed:

#!/bin/bash
# Description: Verify the module structure and exports of @orpc/standard-server-aws-lambda

# Check if the exports match what's being mocked
ast-grep --pattern 'export $$ toStandardLazyRequest'
ast-grep --pattern 'export $$ sendStandardResponse'

# Check the OpenAPIHandler export
ast-grep --pattern 'export $$ experimental_OpenAPIHandler'

Length of output: 169


🏁 Script executed:

#!/bin/bash
# Search for the actual exports in the repository
rg "toStandardLazyRequest" -n
rg "sendStandardResponse" -n
rg "experimental_OpenAPIHandler" -n

Length of output: 15024


Import and mocking setup verified
The exports toStandardLazyRequest, sendStandardResponse, and experimental_OpenAPIHandler all exist and are re-exported correctly at the package entry points. The vi.mock calls in openapi-handler.test.ts match those exports, so no changes are needed.

packages/standard-server-aws-lambda/src/request.test.ts (6)

1-11: Well-structured test setup with proper spying.

The test setup correctly uses vi.spyOn to monitor calls to the utility functions without fully mocking them, which allows testing the actual integration while still being able to verify the call patterns.


18-41: Comprehensive and realistic test data.

The mock API Gateway event includes all the essential fields with realistic values, including cookies, headers, request context, and body data. This provides good test coverage for the conversion function.


43-61: Thorough verification of function integration.

The test correctly verifies that:

  • URL construction works properly
  • Method is correctly extracted
  • Signal, headers, and body are properly delegated to their respective conversion functions
  • Function call patterns match expectations

63-79: Excellent testing of lazy evaluation and override behavior.

This test thoroughly verifies the lazy evaluation mechanism:

  • Headers are not computed until first access
  • Override before access works correctly
  • Override after access works correctly
  • Caching behavior is verified

The test design effectively validates the lazy evaluation contract.


81-95: Good coverage of lazy body evaluation.

The test verifies both override scenarios and caching behavior for the body property, ensuring the lazy evaluation works consistently across different properties.


97-111:

✅ Verification successful

Verify the event-stream test implementation.

The test for event-stream handling looks promising, but I want to verify that the input format and expected behavior align with the actual toStandardBody implementation.

Let me check the event-stream parsing implementation:


🏁 Script executed:

#!/bin/bash
# Description: Verify the event-stream parsing logic in toStandardBody

# Check the toStandardBody implementation for event-stream handling
ast-grep --pattern 'export function toStandardBody($$$) {
  $$$
}'

# Check for event-stream related logic
rg -A 10 'text/event-stream'
rg -A 10 'isAsyncIteratorObject'

Length of output: 90995


Event-stream test implementation verified

The SSE request test in packages/standard-server-aws-lambda/src/request.test.ts matches the actual parsing logic:

  • toStandardLazyRequest delegates to toStandardBody, which on text/event-stream calls _parseAsString then toEventIterator
  • toEventIterator correctly parses "data: \"foo\"" into "foo" and handles the final done event yielding "bar" with done: true

No changes are required here.

apps/content/docs/adapters/http.md (1)

12-16: Good addition to the adapter table.

The table update clearly documents the new AWS Lambda adapter support alongside existing adapters, providing users with a comprehensive overview of available options.

packages/standard-server-aws-lambda/src/signal.test.ts (2)

5-21: Good success case testing.

The test correctly verifies that when a stream ends normally (via stream.end()), the abort signal remains unaborted. The timeout allows for asynchronous completion.


23-43: Thorough error handling test.

The test properly:

  • Sets up an error listener to prevent unhandled error events
  • Verifies the signal is aborted when the stream is destroyed with an error
  • Checks that the abort reason matches the original error
  • Uses vi.waitFor for proper async assertion handling
packages/server/src/adapters/aws-lambda/rpc-handler.ts (3)

1-7: LGTM! Clean and well-organized imports.

The imports are properly structured and follow TypeScript conventions for separating type-only imports from value imports.


9-16: LGTM! Well-designed options interface.

The RPCHandlerOptions type effectively combines multiple option interfaces and adds the AWS Lambda-specific strictGetMethodPluginEnabled flag with a sensible default.


18-24: LGTM! Good documentation and class structure.

The class documentation with links to relevant docs is helpful, and the experimental prefix appropriately signals this is a new feature.

packages/standard-server-aws-lambda/src/headers.ts (2)

6-14: LGTM! Simple and effective header conversion.

The function correctly merges Lambda headers with cookies into the standard format. The use of spread operator and direct property assignment is appropriate here.


16-36: LGTM! Robust reverse conversion with proper edge case handling.

The function correctly:

  • Skips undefined values
  • Handles the special 'set-cookie' header case using toArray utility
  • Flattens other headers using the flattenHeader utility
  • Returns both headers and cookies as a tuple

The implementation is clean and handles edge cases appropriately.

packages/server/src/adapters/aws-lambda/rpc-handler.test.ts (5)

1-17: LGTM! Proper test setup with effective mocking.

The mocking strategy is well-designed:

  • Mocks external dependencies appropriately
  • Uses vi.clearAllMocks() for clean test isolation
  • Preserves the original module while mocking specific exports

19-40: LGTM! Comprehensive test data setup.

The test setup includes:

  • Realistic handler configuration with different route methods
  • Mock event and response stream objects
  • Complete standard request object with all necessary properties

This provides good foundation for the test scenarios.


41-62: LGTM! Thorough testing of successful route matching.

The test properly verifies:

  • Handler returns matched result
  • Correct function calls with expected parameters
  • Proper response format and content
  • Integration between all mocked components

64-82: LGTM! Good coverage of route mismatch scenario.

The test correctly verifies:

  • Handler returns unmatched result
  • Request transformation still occurs
  • Response sending is skipped appropriately

84-111: LGTM! Excellent test for strict GET method enforcement.

This test effectively demonstrates:

  • The StrictGetMethodPlugin is enabled by default
  • GET requests to non-GET routes result in 405 Method Not Allowed
  • Proper error message formatting
  • The plugin works correctly within the AWS Lambda context

This is a crucial test that validates the security feature works as expected.

packages/server/src/adapters/aws-lambda/handler.ts (4)

1-8: LGTM! Well-organized imports with proper type separation.

The imports are cleanly structured, separating type imports from value imports and importing from appropriate packages.


10-14: LGTM! Clean interface and type definitions.

The AwsLambdaHandlerOptions extends SendStandardResponseOptions appropriately, and the AwsLambdaHandleResult provides a clear discriminated union for the result type.


16-24: LGTM! Clean constructor with proper dependency injection.

The constructor follows good patterns:

  • Uses dependency injection for the standard handler
  • Provides sensible defaults for options
  • Stores options for later use in the handle method

26-43: LGTM! Well-designed handle method with proper error handling.

The method implementation is excellent:

  • Converts Lambda event to standard request using the utility function
  • Resolves options using the appropriate utility functions
  • Delegates to the standard handler for business logic
  • Handles both matched and unmatched cases appropriately
  • Sends response only when matched
  • Uses async/await properly throughout

The design follows the adapter pattern effectively, providing a clean interface between AWS Lambda and the standard handler.

packages/standard-server-aws-lambda/src/response.test.ts (6)

12-16: Good test setup with proper AWS Lambda global mock.

The mock setup correctly simulates the AWS Lambda runtime environment by providing a mock HttpResponseStream.from function.


20-54: Comprehensive test for empty body scenario.

The test properly verifies that:

  • toLambdaBody is called with correct parameters
  • AWS Lambda HttpResponseStream is initialized with proper configuration
  • No chunks are written for empty body
  • Stream is properly closed

56-94: Thorough test for JSON body handling.

The test validates JSON serialization and proper content-type header setting. The assertion correctly expects the body to be converted to a Buffer containing the JSON string.


96-140: Excellent streaming test with proper event-stream format verification.

The test correctly validates:

  • Event-stream headers are set appropriately
  • Each yielded value is formatted as an event-stream message
  • Proper Buffer format for chunks

142-195: Robust error handling test with proper cleanup verification.

This test excellently covers the edge case of stream destruction during sending, ensuring:

  • Partial chunks are written before destruction
  • Cleanup logic in generators is executed
  • Error propagation works correctly

197-249: Good coverage of stream destruction without error.

This test complements the error case by testing normal stream destruction, ensuring the cleanup logic works in both scenarios.

packages/standard-server-aws-lambda/src/response.ts (2)

36-44: Excellent stream error handling and cleanup.

The implementation properly handles:

  • Stream cleanup when response stream closes
  • Error propagation from body stream to response stream
  • Proper stream destruction with error context

14-16: Good Promise-based error handling setup.

The Promise setup correctly handles both error and close events from the response stream.

packages/standard-server-aws-lambda/src/types.ts (1)

3-17: Consistent and well-structured auxiliary interfaces.

All the helper interfaces follow a consistent pattern with proper optional string mapping. The structure aligns well with AWS Lambda's flexible header and parameter handling.

packages/standard-server-aws-lambda/src/event-iterator.test.ts (7)

7-39: Excellent test coverage for event parsing with metadata.

The test thoroughly validates:

  • Event parsing with different metadata (id, retry)
  • Proper handling of comments (ping)
  • Correct event metadata extraction and attachment

74-106: Comprehensive error event handling test.

The test properly validates that error events are converted to ErrorEvent instances and thrown appropriately during iteration.


117-134: Thorough stream generation test with return value.

The test validates proper event stream formatting including:

  • Correct event-stream syntax
  • Metadata preservation (id, retry)
  • Return value handling as "done" event

153-189: Excellent error handling tests for both error types.

The tests cover both regular Error objects and ErrorEvent instances, ensuring proper serialization and event formatting.


191-243: Robust cancellation tests with proper cleanup verification.

These tests ensure that:

  • Generator finally blocks are executed on cancellation
  • Stream destruction works correctly
  • Both yielding and throwing scenarios are covered

245-276: Comprehensive keep-alive functionality test.

The test validates timing-sensitive keep-alive behavior with appropriate tolerances. The retry configuration suggests this test may be flaky due to timing, which is handled appropriately.


279-299: Excellent integration test for round-trip conversion.

This parameterized test ensures that data survives the stream→text→iterator conversion cycle, which is crucial for the event system's reliability.

packages/standard-server-aws-lambda/src/body.ts (1)

10-42: Well-structured content type handling!

The function correctly handles all major content types with appropriate fallbacks. The content-disposition check for file detection is implemented correctly.

packages/standard-server-aws-lambda/src/event-iterator.ts (1)

87-156: Excellent implementation of event streaming with keep-alive!

The function properly handles:

  • Configurable keep-alive with sensible defaults
  • Proper cleanup of intervals on completion/error
  • Cancellation support with iterator cleanup
  • Error event encoding

The resource management is particularly well done.

🧰 Tools
🪛 Biome (1.9.4)

[error] 88-88: void is confusing inside a union type.

Unsafe fix: Use undefined instead.

(lint/suspicious/noConfusingVoidType)


[error] 88-88: void is confusing inside a union type.

Unsafe fix: Use undefined instead.

(lint/suspicious/noConfusingVoidType)

@unnoq unnoq merged commit d9485b0 into main May 28, 2025
7 of 8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant