AWS Lambda Node 24 Runtime Error

Is there an existing issue for this?

I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
I have reviewed the documentation https://docs.sentry.io/
I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/node

SDK Version

10.28.0

Framework Version

Nuxt 4.2.1

Link to Sentry event

https://your-menu.sentry.io/issues/7087894413/events/4ed88352510f427091413edf5b2bfea3/?project=4507589965053952&query=is%3Aunresolved&referrer=previous-event

Reproduction Example/SDK Setup

The Node 24 runtime in AWS Lambda appears to be incompatible with Sentry (@sentry/node -- underlying @sentry/nuxt in our case). It is likely an OpenTelemetry issue, but not sure exactly which package.

After upgrading the runtime in AWS, we immediately started being flooded with this error:

TypeError: this.invokeStore.getTenantId is not a function
    at TelemetryLogger.log (/var/runtime/index.mjs:1479:39)
    ...

It appears that anywhere in the application where console.log() or console.error() etc. was called, this error would be triggered. I removed the logging integration from Sentry, just in case that was the cause, but, as I had kind of already assumed, did not resolve the issue.

I figured, based on the class name, that this is from otel, and I did find this issue, but nothing exactly related.

Hoping someone here who has more knowledge of how the packages all sort themselves out can file an appropriate report.

There's probably some combination of settings that could remove this TelemetryLogger call, but that would probably take away from what we're trying to get out of Sentry. So, for now, I just swapped back to Node 22 and everything is fine again.

Steps to Reproduce

Use console.log() somewhere in the deployed application.

Expected Result

No errors generated in Sentry.

Actual Result

TypeError: this.invokeStore.getTenantId is not a function

Additional Context

No response

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

JS-1256

@brtinney

Hi @brtinney, thanks for filing this.

We'll look into it.

@brtinney

@brtinney I tried to reproduce this both with our AWS Lambda Layer as well as with a plain @sentry/node self-created layer and a simple lambda function but I wasn't able to reproduce this.

I also tried deploying a nuxt project with sentry to aws and running that on node 24 -> no issues.

Could you please provide a reproduction repo?

Apologies, it appears my simple repo I used for #18238 does not have this issue on Node 24, so there must be another complicating factor.

Unfortunately, the stack trace in Sentry doesn't help me figure out the source of the issue. If I remove the environment variable NODE_OPTIONS=--import ./.output/server/sentry.server.config.mjs, the error does not occur, so it does seem related to Sentry being loaded in. Working on adding various pieces to the minimal repo until it triggers the error again now.

It appears that loading the AWS Step Function Client and Sentry together (and then using console.log()) will cause the error for the Node 24 runtime.

If you add this as a middleware (so it is loaded on every server route), it will trigger the error when you try to console.log() in your route:

import { SFNClient } from '@aws-sdk/client-sfn'

import * as Sentry from '@sentry/nuxt'

const stepClient = new SFNClient({
  region: 'us-east-1',
  credentials: {
    accessKeyId: 'abc',
    secretAccessKey: 'abc'
  }
})

const error = async () => {
  Sentry.captureException(new Error('An exception'))
}

export default defineEventHandler(async (event) => {
  const user = { error }

  event.context.admin = user
})

If you remove Sentry (i.e. the Sentry.captureException line) or the Step Function Client (i.e. the stepClient line), there is no error.

I wish it was more straightforward than that, but at least I finally got it down to just that interaction, as it was a bit of a chore to tease out of the full project.

For my reproduction, I used just a minimal Nuxt project with the aws-lambda Nitro preset, a very basic Sentry config (just the DSN, release, environment), and added the below API endpoint with the above middleware for the server, then uploaded and configured the NODE_OPTIONS as described above.

export default defineEventHandler(() => {
  console.log('test-event')

  return { message: 'test-event' }
})

I also found (oddly enough) that if you move the code from the middleware into the API route (i.e. all the imports/definitions into the file and the two lines into the route function itself), it will no longer error. As a result, I'm wondering if it is something with how Sentry is hooking into Nuxt's event object and/or Nuxt's middleware. But clearly this has something specific to do with AWS's environment as well.

If I'm being completely honest, unless this immediately triggers a solution in someone's mind or is more widespread, this is probably something to ignore, and I'll just check in on periodically after package updates. It won't be a critical until 2 years from now when AWS stops supporting Node 22, so I'd hope that this resolves itself before then, one way or another.

Thanks for the details and going through this, this'll help narrow it down. I remember we've had some issues in the past around nuxt and middlewares, might be somewhat related.

We'll take a closer look.

@brtinney

I finally had the chance to look over this again and it looks like this is actually a bug with AWS's own runtime. The runtime and the AWS sdk each bundle a copy of @aws/lambda-invoke-store that share a single instance via globalThis.awslambda.InvokeStore. The first copy that is loaded wins.

getTenantId was added to that package in version 0.1.1. Some AWS versions (e.g. @aws-sdk/client-sfn@3.910.x) bundle an older 0.0.1 copy that lacks it. When that older copy loads first and registers on the global, the runtime adopts it and crashes on the next console call.

Our SDK is only an indirect trigger to this. Because we preload via --import, we pull in the AWS SDK which is the copy that's broken and because it comes first it wins and you're running into this.

@brtinney which version of the AWS sdk are you using? I suggest upgrading that, alternatively, an override in your package.json could potentially help:

{
  "overrides": {
    "@aws/lambda-invoke-store": "0.1.1"
  }
}

Let me know if that helps, and apologies for the long radio silence.

@andreiborza

Hi @andreiborza -- thanks for running this down. I can confirm that forcing the resolution to 0.1.1 resolves the issue for us on AWS Lambda's Node 24 runtime. Without that, it appears our build process was bundling 0.0.1.

Following up here to note that this was actually a mistake from our vite configuration -- @aws/client-sfn was the only package we hadn't externalized, which is why it was being included in the final bundle. We attempt to just use the bundled versions running in the Lambda environment to avoid this kind of situation in the first place (but apparently missed this one).

@brtinney

@brtinney thanks for the extra info, this should help other users arriving at this issue.

Navigation Menu

Repository navigation

AWS Lambda Node 24 Runtime Error #18412

Is there an existing issue for this?

How do you use Sentry?

Which SDK are you using?

SDK Version

Framework Version

Link to Sentry event

Reproduction Example/SDK Setup

Steps to Reproduce

Expected Result

Actual Result

Additional Context

Priority

2 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

AWS Lambda Node 24 Runtime Error #18412

Description

Is there an existing issue for this?

How do you use Sentry?

Which SDK are you using?

SDK Version

Framework Version

Link to Sentry event

Reproduction Example/SDK Setup

Steps to Reproduce

Expected Result

Actual Result

Additional Context

Priority

Activity

linear commented on Dec 4, 2025

andreiborza commented on Dec 5, 2025

andreiborza commented on Dec 12, 2025

brtinney commented on Dec 12, 2025

2 remaining items

brtinney commented on Dec 15, 2025

andreiborza commented on Dec 16, 2025

andreiborza commented on Jul 15, 2026

brtinney commented on Jul 21, 2026

brtinney commented on Oct 28, 2026

andreiborza commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions