Question 385531 in Amazon Web Sevices Question posted in
The official Amazon Web Services documentation can be found here.

Amazon web services – Finding the "true" code version of AWS Lambda runtime

The Issue

We ran into a situation where an AWS lambda runtime version update appears to be causing issues with our code.

This works (nodejs 18.v24; also .v26 works):
enter image description here

This does not work (nodejs 18.v28):
enter image description here

However, those version numbers do not correspond to actual Node versions that I can find. On the Node site, the latest version of 18 is 18.20.2 (as of this writing).

enter image description here

The Question

How do I find the actual Node version behind the AWS version number so I can compare differences between v.26 and v.28 to try to determine what update might be causing issues with our code?

Tags:

2

Answers


  1. 0

    Not an answer, but I have the same issue. Lambda Node 18 v28 breaks my code, whilst v26 works fine. Lambda auto updated node 18 v26 -> v28, but this should be a minor patch, thus not break stuff.

    From Node 18 Github, the latest LTS is 18.20.2, which was released April 10th.

    The AWS Node 18 container was updated on the between 17th -> 19th of April. I think there’s a non-zero probablity that Node 18 v28 Lambda is 18.20.2. But why would a security patch break code?

    Error: Protocol error: Connection closed. Most likely the page has been closed
node_modules/puppeteer-core/lib/cjs/puppeteer/util/assert.js:28:15
    Login or Signup to reply.
  2. 0

    The Lambda runtime version does not correlate to the Node.js minor version, so for example the runtime version "nodejs 18.v24" does not mean it should be using Node.js version 18.24.x, rather it’s the 24th time aws has updated the nodejs18 runtime.

    The issue is likely being caused by a dependency, normally a patch version wouldn’t cause an issue like that so it might be a rare issue that’s difficult to find

    As a temporary solution it looks you can set the lambda runtime manually and stop it from updating it so you can have some time to find the issue then update the runtime version. There is some information in the aws documentation about this:

    In the rare event that a new runtime version is incompatible with your existing function, you can roll back its runtime version to an earlier one. This keeps your application working and minimizes disruption, providing time to remedy the incompatibility before returning to the latest runtime version.

    I’m assuming your lambda function is currently using the $LATEST version by default, and must be automatically updating the runtime version as well, so these instructions might be what you need

    If you’re using the Auto runtime version update mode, or you’re using the $LATEST runtime version, you can roll back your runtime version using the Manual mode. For the function version you want to roll back, change the runtime version update mode to Manual and specify the ARN of the previous runtime version.

    You can get the ARN of the working version from the labda logs you posted with the question

    These are documentation pages I found this info from

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search