AWS callback warning

[amoffat]

In my AWS logs for a S3 Bucket notification lambda that uses serverless-express, I get the following warning:

AWS Lambda plans to remove support for callback-based function handlers starting with Node.js 24. You will need to update this function to use an async handler to use Node.js 24 or later. For more information and to provide feedback on this change, see https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/issues/137. To disable this warning, set the AWS_LAMBDA_NODEJS_DISABLE_CALLBACK_WARNING environment variable.

This is how I'm creating the request handler:

export const handler = serverlessExpress({
  app,
  eventSourceRoutes: {
    AWS_S3: "/s3",
  },
});

Seems like serverless-express may need some internal update to be compatible with the new AWS updates?

Edit>> My version is 4.16.0

[brettstack]

Safe to ignore that warning. SE supports callback for backwards compatibility

[amoffat]

Thanks. Feel free to close if removing that backwards compatibility is not on the roadmap

[rdsedmundo]

@brettstack this is no longer true with Node.js 24, and even within the Node.js 22 runtime, if Managed Instances are being used it will throw:

ERROR: AWS Lambda does not support callback-based function handlers when using Node.js 22 with Managed Instances. To use Managed Instances, modify this function to use a supported handler signature. For more information see https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html.

They are checking for this via the Function.length parameter, so if backwards compatibility is desired the callback parameter shouldn't be called explicitly but checked either through ...args or arguments directly.

[ethanherbertson]

Can we get clarification on whether this is truly safe to ignore? @brettstack are you sure the backwards compatibility works like we want under Lambdas running Node 24?

[brettstack]

Lame that they're just checking the function signature length. Please try the v5 beta which removes callback 5.0.0-beta.1.

[ethanherbertson]

Following-up on this: Unfortunately I'm not in an ideal position to exercise the changes for the v5 beta; it turns out my project's use of Serverless Express actually inoculates against this callback deprecation anyway, as we've got a Lambda handler of our own that technically handles the event rather than Serverless Express directly. I did give the beta version a shot and didn't run into issues, but since I've got that go-between code in there, it's probably not relevant feedback.

One thing that probably is relevant, though, is that as of last week, the @types/aws-lambda module's team wasn't yet working towards a version of its Handler type with that callback argument removed (or optional), so anybody wanting to themselves invoke the function returned by serverlessExpress() in TypeScript (as I am, during my own Lambda handler function) will likely run into a situation where they'll still have to pass in a dummy callback argument, even under v5, at least until the @types team figures out how they want to proceed.

[rdsedmundo]

@brettstack The beta version is working for us. Is there a timeline to move it to the latest tag?

[mdgm88]

The beta version is also working for me.

[rdsedmundo]

Actually, the change done on #555 was rather problematic for us. I had to manually patch the package on our side reversing that changeset. It's also not explicitly mentioned as a breaking change in the release notes.

For years we've declared our route in the Serverless Framework as:

  handleWebhook:
    handler: src/handlers/handleWebhook.handler
    events:
      - http:
          method: POST
          path: /event

And then our Express app would handle it as:

router.post(
  '/event',
  bodyParser.raw({ type: 'application/json' }),
  async (req, res) => {

But now the /event wasn't being caught anymore, instead it was resolving to / (because API Gateway's "resolver" property is /event).

Not sure if it's expected or not? But I don't think it's something that we'd probably personally want since we also invoke the Express App standalone as a Node.js app for local development purposes, and we'd need to adapt the route for the difference use case.

[mdgm88]

Interesting. I couldn't get this package to work for me until I tried the new beta version which includes #555

Though that could also be because I am using node 24.