AWS Lambda Node 24 Runtime Error

[brtinney]

Is there an existing issue for this?

• [x] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• [x] I have reviewed the documentation https://docs.sentry.io/
• [x] 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.}

[linear[bot]]

JS-1256

[andreiborza]

Hi @brtinney, thanks for filing this.

We'll look into it.

[andreiborza]

@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?

[brtinney]

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.

[brtinney]

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.

[andreiborza]

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.