Feature request: LLRT support for Event Handler

[perpil]

Use case

Along with the Metrics and Logger modules, since building a REST API is a popular use case for using Lambda, the event handler should be tested with LLRT for compatibility.

Solution/User Experience

Currently when you run the sample from the docs using the LLRT runtime (v0.6.2 beta):

import { Router } from '@aws-lambda-powertools/event-handler/experimental-rest';
import type { Context } from 'aws-lambda';

const app = new Router();

app.get('/ping', async () => {
  return { message: 'pong' }; 
});

export const handler = async (event: unknown, context: Context) => {
  return app.resolve(event, context);
};

It spits out:

[Object object]

Instead of

{
  "message": "pong"
}

The issue could be with LLRT, but it would be useful to understand what the current issue is so these two pieces of tech can work together at some point.

Acknowledgment

• This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[dreamorosi]

Hi David, nice to see you here!

I just deployed a basic stack on Node.js 22 and it works:

Generally speaking the main goal for us at the moment is to deliver the best experience on Lambda's managed runtimes and leverage Node.js APIs as much as possible/needed. Because of this LLRT support, at least for now, is to be considered as best effort.

We won't intentionally ship features that prevent Event Handler from running on LLRT, and in case of compatibility issues we'll be open to make reasonable and non-performance impacting changes to remove these blockers, similar to what we did in the past for Logger.

However, if it ever comes down to deciding between LLRT support and a sub-par / less performant / worse DX experience in the managed runtime, we'll almost definitely lean towards the latter. This is in line with the fact that managed runtimes are officially supported by AWS while LLRT is still experimental.

I'm more than happy to leave the issue open as channel for you or others who want to test Event Handler with LLRT and report issues, so we can discuss them and evaluate the best course of action on a case by case basis.

---

Regarding this specific behavior at first I thought it had something to do with LLRT's bootstrap script but if you change the code to this and log the response returned by app.resolve you see that the [object Object] is already there:

export const handler = async (event: unknown, context: Context) => {
  const res = await app.resolve(event, context);

  logger.info('Response:', { res });

  return res;
};

This leads me to think the issue is somewhere around here, which is where we convert the return value of your route handler to a response.

This is confirmed by the fact that if you change your handler to this (aka handling the response object creation yourself), which corresponds to this code path, the module works fine with LLRT:

app.get('/ping', async () => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'pong' }),
  };
});

With that in mind, looking at the implementation of the function that appears to be problematic, the only line that I think can be the culprit is this one. If you patch in a log statement like below, you see the pesky [object Object] there:

const body = await response.text(); // this is the issue
console.log('here6', { body })
const result = {
  statusCode: response.status,
  headers,
  body,
  isBase64Encoded: false,
};

After a bit of digging however I think I found the actual issue, which is this line.

I don't know for sure, but I'm thinking that the Response.json() static method is either not implemented or faulty on LLRT's side, which you can confirm by running these lines:

const stuff = Response.json({ message: 'pong' });
console.log('stuff', { stuff }); // 
console.log('stuff body', await stuff.text()); // [object Object]

which on Node.js 22 they log this:

[/aws/lambda/PongFn] 11:44:28 PM 2025-09-16T21:44:28.464Z       3d8cb49f-ec3f-4333-b08f-a1d00fe4acd1    INFO    stuff {
  stuff: Response {
    status: 200,
    statusText: '',
    headers: Headers { 'content-type': 'application/json' },
    body: ReadableStream { locked: false, state: 'readable', supportsBYOB: true },
    bodyUsed: false,
    ok: true,
    redirected: false,
    type: 'default',
    url: ''
  }
}
[/aws/lambda/PongFn] 11:44:28 PM 2025-09-16T21:44:28.465Z       3d8cb49f-ec3f-4333-b08f-a1d00fe4acd1    INFO    stuff body {"message":"pong"}

while on LLRT log this:

[/aws/lambda/PongFn] 11:46:12 PM 2025-09-16T21:46:12.666Z       4b0c038b-f2c2-403a-9bfc-517b43eff52d    INFO    stuff {
  stuff: Response {
    headers: Headers {},
    bodyUsed: false,
    body: undefined,
    url: '',
    redirected: false,
    ok: true,
    statusText: 'OK',
    status: 200,
    type: 'basic',
    Symbol.toStringTag: undefined
  }
}
[/aws/lambda/PongFn] 11:46:12 PM 2025-09-16T21:46:12.666Z       4b0c038b-f2c2-403a-9bfc-517b43eff52d    INFO    stuff body [object Object]

Using this static method is not particularly critical since it's just a syntactic sugar around creating a Response object with JSON body and appropriate header, which can be patched/replaced with this (which works on LLRT):

new Response(JSON.stringify({ message: 'pong' }), {
    headers: { 'content-type': 'application/json' },
  });

However I still suggest we open an issue on LLRT and try to get it fixed on their side - this should give us an idea of whether they're also willing to make changes to support our feature.

[perpil]

Thanks for the thorough investigation!

Generally speaking the main goal for us at the moment is to deliver the best experience on Lambda's managed runtimes and leverage Node.js APIs as much as possible/needed. Because of this LLRT support, at least for now, is to be considered as best effort.

Totally agree here! I only raised this because it seemed very close to working just like Logger and Metrics were when llrt launched.

However I still suggest we open an issue on LLRT and try to get it fixed on their side - this should give us an idea of whether they're also willing to make changes to support our feature.

Yes, I'll cut an issue to llrt, they've been very responsive to requests I've made and fixed them quickly.

I think the issue is that the json method returns a Value<'js> which doesn't have a to_string() method so it uses the default. I think it should call JSON.stringify on it before returning it.