Node.js 14
Closed this issue · 9 comments
I got a notice from AWS:
"We are ending support for Node.js 14 in AWS Lambda. This follows Node.js 14 End-Of-Life (EOL) reached on April 30, 2023 [1].
As described in the Lambda runtime support policy [2], end of support for language runtimes in Lambda happens in two stages. Starting November 27, 2023, Lambda will no longer apply security patches and other updates to the Node.js 14 runtime used by Lambda functions, and functions using Node.js 14 will no longer be eligible for technical support. In addition, you will no longer be able to create new Lambda functions using the Node.js 14 runtime. Starting January 25, 2024, you will no longer be able to update existing functions using the Node.js 14 runtime.
We recommend that you upgrade your existing Node.js 14 functions to Node.js 18 before November 27, 2023."
And this shows that the AGC logging is using Node.js 14:
aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='nodejs14.x'].FunctionArn"
Returns:
arn:aws:lambda:us-east-1::function:Agc-Context---LogRetentionaae0aa3c5b4d-JWxtx4CDVz1W:$LATEST
Operating System:
AGC Version: v1.6.0
-Standard AGC setup, running a Nextflow pipeline.
I can no longer deploy snakemake contexts because of this. The Log Retention Lambda fails with "Resource handler returned message: "The runtime parameter of nodejs14.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs20.x) while creating or updating functions."
Also getting this error trying to run the 'Hello World' test after installation following the Getting Started documentation: https://aws.github.io/amazon-genomics-cli/docs/getting-started/helloworld/
"Stack Deployments Failed: Error: The stack named Agc-Context-Demo-jackroyleLpd1z-myContext failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: Resource handler returned message: "The runtime parameter of nodejs14.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs20.x) while creating or updating functions. (Service: Lambda, Status Code: 400, Request ID: a432e8f8-a267-4149-944e-cc3ce86a6710)" (RequestToken: 7d5ecefb-45f6-aa16-9061-d52d768e7ef2, HandlerErrorCode: InvalidRequest)"
Have tried installing Nodejs as described in the documentation, and also installing NodeJS 20, both resulting in the same error.
I am also getting this error while deploying a miniwdl context for a new pipeline. No issues when I installed miniwdl and Cromwell contexts in the past 2 weeks as the issue only started occurring today.
Looks as if the aws-cdk needs to be updated as the current version uses nodejs.14.x when creating lambdas.
The stack deployment from agc context deploy will fail due to the current setup where aws-cdk-lib is pinned to version 2.50.0. Version 2.50.0's LogRetention function is hard-coded to use nodejs14.x, which is now fully deprecated (for evidence, see https://www.npmjs.com/package/aws-cdk-lib/v/2.50.0?activeTab=code and navigate to /aws-logs/lib/log-retention.js.
Later versions, such as aws-cdk-lib 2.129.0 (current as of this moment) pin later runtimes, currently using nodejs18.x which is still supported.
I am looking into a workaround. For the moment, the agc context deploy command is completely broken.
Issue Description:
When deploying my Amplify project, I encountered the following error during the backend deployment phase:
Resource handler returned message: "The runtime parameter of nodejs14.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs20.x) while creating or updating functions. (Service: Lambda, Status Code: 400, Request ID: 2fdb0891-8a62-4fd8-89cc-c5ce20ef4a51)"
This issue has started occurring recently; previous deployments were successful. A prompt solution or workaround would be greatly appreciated.
Yeah, the versioning is a bit of a mess. I'm wondering if an AddPropertyOverride could be used to force the runtime up to nodejs20.x. I'm just having trouble finding where it's actually creating that resource.
All righty -- here's why it all happens. This is assuming you've already gotten the background from this post.
Background
Lambda Functions in CDK, by default, do not create Log Groups at CDK deploy time. Log Groups are typically find-or-created when the Lambda executes for the first time.
HOWEVER, there are certain scenarios where the CloudFormation stack needs to know what the Log Group will be. For example, if the Function's log retention needs to be set to a specific value, or if some other resource needs to know the Log Group's properties.
In THESE cases, CDK will generate a Custom::LogRetention resource in the background, intended to set retention and return metadata about a Lambda's Log Group. You guessed it, this Custom Resource is itself a Lambda with a runtime of...drumroll...nodejs14.x (at least in CDK 2.50.0). So that's where our problems lies.
Diving Deep
The question is...why does this get created in this case at all? There's no mention of log retention ANYWHERE in this CDK application. However, careful readers may have picked up on this already: the custom resource also gets created if we're ever reading Log Group metadata. Which we're doing in each of the 4 engine constructs (eg.
). That seemingly inoffensive line of code is causing huge deployment issues down the line.Solutioning
The next question is what would happen if we just...removed these offending lines of code. And the answer is...pretty much nothing. Setting this.adapterLogGroup = lambda.logGroup is effectively unnecessary because the only time that adapterLogGroup property is used is as a CfnOutput (which already has error handling if the value is undefined!!).
Therefore, my proposal is to comment out these 4 lines of code. If someone wants to see the Log Group name, they can look it up from the Lambda at Lambda-execute time. I will be submitting a PR for this.
^ As a workaround until this is mainlined, you can update these files in your ~/.agc folder and then re-run agc context deploy. It should skip the offending Lambda creation.