Some of my AWS Lambda functions started crashing around January 2023, although I did not publish an update in the meantime. The chances are high that it is caused by an update of the managed runtime.
I would like to revert the runtime used on those specific functions to a prior version that is known to work.
The possibility to handle runtime versions on AWS Lambda is very new at the time of writing. Log files now show a line indicating the ARN of the runtime used.
For instance, in my case: arn:aws:lambda:eu-west-1::runtime:be4a32da6aeaa90583d476cb548ced79ae2c9aa7b14a45129198bbd13ea5822d
The new configuration options allow to force the use of a specific runtime version instead of the latest. Which would solve my problem, at least temporarily. There is no list to select from; the exact ARN has to be provided instead.
But it is not possible AFAIK to guess the ARNs of runtime versions used before January 24, 2023. How can I get those?
For the technical details, this is a NodeJS 14 environment, and the function uses C++ dependencies built using node-gyp. The newly-introduced crash is due to GLIBCXX_3.4.29 not found in the native code.
Related
Could you please help me understand how to specify the nodejs runtime version of the lambda function that gets automatically created by aws when a new data bucket with parameter
autoDeleteObjects: true is created?
I am using the following piece of code:
const autoDeleteBucketProps = { autoDeleteObjects: true, removalPolicy: >cdk.RemovalPolicy.DESTROY };
new Bucket(this, 'store', {
...bucketProps,
...autoDeleteBucketProps
});
This code automatically creates a lambda function with runtime version Node.js 12.x for autodeleting objects. However due to the fact that Amazon requires that we upgrade our lambda runtimes (ending support of v12 as described in Lambda runtime support policy), I am trying to a find a way to upgrade the runtime of this automatically created lambda to version 14.
I am using aws-cdk v1.152.0 which supports '#aws-cdk/aws-lambda' Runtime version v14. So why this lambda gets created with runtime v12? And how can it can be changed to v14, programmatically?
Thank you in advance.
I just updated one of our stacks from CDK 2.23.0 to 2.46.0 and the auto deletion lambda automatically updated to Node 14 runtime.
You said you were using CDK 1.152.0 and if for some reason you want to stick with V1, it should also update to the new runtime in 1.176.0, but I have not tested this myself. I was just reading the changelog notes of CDK.
Updating to CDK v2 was quite easy for us at least and I think v1 is nearing end-of-life so I suggest you move to v2 now or soon.
I think you should be able to update the runtime in the console or remake the function when v12 is no longer used.
You can find more details on the lambda runtimes here
We have a project built with NodeJS. With time the version upgrades are very necessary but while updating the version, if we do not have enough test cases, something might break and we may know it far later. Such a scenario was introduced when replaceAll method was used in some part of the code. But replaceAll is not supported until NodeJS 15 or later. So we run into trouble after merging the code.
Can we check whether the NodeJS code works or not for a specific version?
Demonstration:
I've created a repository on GitHub for this with a workflow to demonstrate the problem. See this run https://github.com/kiranparajuli589/node-check/runs/7573211393?check_suite_focus=true
Here I've used Node 14 and properly configured the engines keyword in the package.json but still, the linter is not reporting about the usages of such functions that are not available.
I am running javascript Lambda functions that required NodeJS version 14.x. I can manually set this in the AWS Lambda console here (screenshot below), but every time I use the amplify CLI to push a change of the function, it gets reverted back to 12.x. I can't find any reference to the NodeJS version in the local amplify files, or online. Is there a way to keep it from reverting every time?
This is what the Lambda console option looks like, which I edit to 14.x constantly, but it changes back to 12.x:
Currently (26 July 2021), AWS Amplify only support NodeJS ver 12.x. Please see the Supported Lambda runtimes paragraph in the Amplify Docs for reference.
While #matsev's answer looks to be the official version supported by AWS, I noticed that while some of my functions continued to be reverted to 12.x, others stayed at 14.x even after a push. The ones that stayed at 14.x were my more recently created functions.
It turns out, you can edit the *.cloudformation-template.json for each function to set the nodejs version! This file did not appear in my vscode search due to a previous developer hiding it using files.exclude. This is likely a good best practice because the file is meant to be just edited using the amplify CLI, but there are obviously some settings that are not part of the CLI commands. Another example is the timeout parameter in here.
The file is located at: amplify/backend/function/FUNCTION_NAME/FUNCTION_NAME-cloudformation-template.json
The parameter to edit is: `Resources.LambdaFunction.Properties.Runtime = "nodejs14.x"
I'm relying on Node version 12.17.x to make use of a specific feature (AsyncLocalStorage) in Lambda and Elasticbeanstalk. But for some reason, the Node.js version does not seem to publicly available. Why do they think that platform "12.x" tells me the real Node version? I want to know the exact minor and patch version, or at least give some news about it...
I had to create a test lambda function that prints process.version, but surprisingly, platform 12.x still uses v12.16. When will they upgrade to the latest stable version that came out more than 2 weeks ago? Are they publishing those releases somewhere? Google tells me nothing useful.
The same applies to Elasticbeanstalk instances. Node v12.17 does not exist in /opt/elasticbeanstalk/node-install/*
I've just checked in our sentry and the current version is newer-v12.18.4 so you can safely use AsyncLocalStorage now on v12 lambdas.
But AWS should really show this in the lambda administration panel. The fact that this is not shown anywhere and we have to use console logs or third party tools to get this info is a very poor DX.
What is the best practice for using runtime version given that the runtime introduced breaking changes, and using specific version will cause issue given that runtime will be removed regularly.
https://github.com/Azure/app-service-announcements-discussions/issues/90
Please let me explain below:
Scenario 1:
When below is used,
FUNCTIONS_EXTENSION_VERSION =~2
Our code broke with the latest runtime. Because ~2 means it uses the latest version.
https://github.com/Azure/azure-functions-host/issues/4203
Scenario 2:
However, when below is used,
FUNCTIONS_EXTENSION_VERSION = specific version
Our code brok again with the latest runtime. Because the specified runtime is removed by Azure Functions, and the latest runtime with breaking changes is used instead,
https://github.com/Azure/app-service-announcements-discussions/issues/90
Again, what is the better way to reduce the error?
Updates
In terms of time frame, how a latest runtime works when it is publicly downloadable and it is rolled out on Azure Functions? For example, how advance is the runtime available before it is rolled out to Azure fucntions?
How long will an old runtime be kept for on Azure Functions after latest runtime rollout? Based on what factors are an old runtime decided to be deteled?
The best and recommended practice is to use the latest. It is a rare occurrence, but unfortunately, a regression was introduced with a new release impacting your app.
If you want to perform validation on new versions, the recommendation is to:
Subscribe to new release notifications at
https://github.com/Azure/app-service-announcements/issues
Pin yourself to the current release you've validated against
As a new version is introduced, update a test environment to adopt that new version (or have a test environment that auto updates, using ~2). If you have a test environment set with auto-updates and automated tests, this makes the process significantly simpler.
Once validated, update the production environment to that new version
If you find an issue, reporting allows us to ensure we don't remove
the version that works.
We always maintain the newly deployed version and the previous release, and, aside from hotfixes and small ad-hoc deployments, the release cadence is ~2 weeks. Anything that has been flagged as a version that needs to be kept due to issues intruduced by a release (forcing customers to pin) is also kept.