aws-lambda-dotnet icon indicating copy to clipboard operation
aws-lambda-dotnet copied to clipboard

deploy-servereless of netcoreapp2.1 fails when upgrading from netcoreapp2.0

Open TommyN opened this issue 5 years ago • 13 comments

Error message:

The runtime parameter of dotnetcore2.0 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (dotnetcore2.1) while creating or updating functions. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: d64414cd-885e-11e9-8e36-17648db3e023)

I've previously successfully upgraded from netcoreapp2.0 to netcoreapp2.1 but I'm wondering if I'm hitting a snag now that .NET Core 2.0 is EOL:

Code updates to existing functions using .NET Core 2.0 will be disabled 30 days later on May 30, 2019.

I'm using Visual Studio and I'm running:

dotnet lambda deploy-serverless

The error message indicates that my code is dotnetcore2.0, but this is not the case.

Zipping publish folder "....\bin\Release\netcoreapp2.1\publish to ...\bin\Release\netcoreapp2.1\MyAppAwsServerless.zip

aws-lambda-tools-defaults.json

"framework"     : "netcoreapp2.1",

serverless.template

"framework"     : "netcoreapp2.1",

Since I've only used Visual Studio (project template) to generate and deploy the project, I'm wondering if the auto-generated CloudFormation stack is causing the problem?

When I log into the AWS Console and inspect the stack, it looks like:

AWSTemplateFormatVersion: 2010-09-09
Description: >-
  An AWS Serverless Application that uses the ASP.NET Core framework running in
  Amazon Lambda.
Resources:
  ProxyFunction: <snip>
...
              Timeout: 30
      Runtime: dotnetcore2.0

Could it be that I'm not able to update the stack, because the existing template (CloudFormation stack) has "dotnetcore2.0" in it, even though the new code is dotnetcore2.1?

FYI - I updated our other serverless lambda functions before the code update limit:

Code updates to existing functions using .NET Core 2.0 will be disabled 30 days later on May 30, 2019.

that worked fine so that's why I'm wondering if this could be the issue.

Workaround

While writing this ticket I thought I should try to manually update my lambda (using the AWS console) with the .zip created during:

dotnet lambda deploy-serverless

Updating the Lambda manually worked fine and now I'm able to update the Lambda from the command line without errors!

Problem The tooling is unable to update from dotnetcore2.0 to dotnetcore2.1 now that 2.0 is EOL. Updates are rejected even though the application is dotnetcore2.1

TommyN avatar Jun 06 '19 14:06 TommyN

I'm a little confused what have done as part of your upgrade process. In the CloudFormation template have you changed the dotnetcore2.0 to be dotnetcore2.1?

normj avatar Jun 17 '19 16:06 normj

I'm a little confused what have done as part of your upgrade process. In the CloudFormation template have you changed the dotnetcore2.0 to be dotnetcore2.1?

@normj, I guess I did indirectly. I only used the AWS Console, navigated to my Lambda and manually uploaded a new zip with code targeting dotnetcore2.1.

After I did this, dotnet lambda deploy-serverless started working again.

I would have expected the Visual Studio tooling (lambda deploy-serverless) to be able to upgrade the lambda from dotnetcore2.0 to dotnetcore2.1 directly though.

This issue only appeared once dotnetcore2.0 was EOL. Upgrading from dotnetcore2.0 to dotnetcore2.1 in the period when dotnetcore2.0 was deprecated but you were still allowed to update existing lambdas worked fine AFAIR.

Could it be that the CloudFormation template is updated after the fact? Since the current version has dotnetcore2.0, it stops the upgrade event though what you are trying to upgrade with is dotnetcore2.1!?

TommyN avatar Jun 18 '19 10:06 TommyN

If your CloudFormation template had Runtime set to dotnetcore2.0 and you changed the template to be dotnetcore2.1 and redeployed with dotnet lambda deploy-serverless that should have changed the function. CloudFormation will compare the last deployed template to the new one and see that you changed the runtime and perform that operation.

If you did change the runtime in the Lambda AWS Console that would have caused your Lambda function to drift from what the deployed CloudFormation template says. I suspect something got confused between updating in the template and the Lambda console.

normj avatar Jun 18 '19 17:06 normj

Perhaps I'm not explaining it properly. I've only used the Visual Studio tooling and dotnet lambda deploy-serverless. I don't really know anything about CloudFormation at this point.

The reproduction steps below (after the fact) is how I got into the issue.

How to reproduce

  • Create a new project in Visual Studio -> AWS Lambda -> AWS Serverless Application with Tests
  • Make sure the project is dotnetcore2.0
  • Deploy by right clicking the project and selecting "Publish to AWS Lambda..."
  • Check the "Save settings to aws-lamba-tools-default.json"
  • Wait a few months for dotnetcore2.0 to be EOL (both updating and creating new lambdas).
  • In Visual Studio make the project target dotnetcore2.1
  • Update aws-lambda-tools-defaults.json and set Framework: netcoreapp2.1
  • Update serverless.template template and set Framework: netcoreapp2.1
  • Try to deploy the new version

Expected result The AWS Lambda is updated

Actual result Deployment fails with:

The runtime parameter of dotnetcore2.0 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (dotnetcore2.1) while creating or updating functions. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: d64414cd-885e-11e9-8e36-17648db3e023)

Workaround Manually update the AWS Lambda function in the AWS Console, uploading the .zip produced when trying to deploy. After this, deployment from Visual Studio/command line works.

Final notes When you issue dotnet lambda deploy-serverless it mentions CloudFormation, that is why I poked around in the AWS Console and found that the CloudFormation template had "Runtime: dotnetcore2.0".

I don't know why manually updating the AWS Lambda fixed the problem, and at this point I guess it's not possible to reproduce since you would have to have an existing dotnetcore2.0 serverless project to test the upgrade with.

I'm fairly certain that the exact same steps worked fine in the EOL period when you were still allowed to update existing dotnetcore2.0 projects.

TommyN avatar Jun 19 '19 07:06 TommyN

I think what was missing in your steps was updating the serverless.template file in your project. In an AWS Serverless Application project a serverless.template file is added to the project which is a CloudFormation template that defines all of the AWS resources to be created during deployment. The Lambda function is defined in the file and there is a Runtime property that needs to be updated to dotnetcore2.1. image

Our tooling should have done a better job validating what the project was compiled for versus the Lambda runtime and warned with a better error message.

normj avatar Jun 19 '19 19:06 normj

I see I wrote Framework in my reproduction steps for serverless.template, but I meant Runtime: image

If the serverless.template was not updated to dotnetcore2.1, I assume that dotnet lambda deploy-serverless would keep failing even after manually updating the Lambda.

  • dotnet lambda deploy-serverless -> fail
  • AWS Console - upload lambda .zip manually
  • dotnet lambda deploy-serverless -> success

Now that all our functions are updated to ".NET Core 2.1 (C#/PowerShell)" it's not possible for me to reproduce this. I had no problems upgrading the other functions to dotnetcore2.1 using the same steps and tooling, but once 2.0 was EOL'ed from updating existing functions, it failed.

I will keep this issue in mind once dotnetcore2.1 is EOLed so I can prove I'm not going bonkers ;)

TommyN avatar Jun 20 '19 07:06 TommyN

Hello, I'm getting the exact same issue, except the workaround isn't working. I've updating my Visual Studio project to use dotnetcore2.1 and within CodeBuild, I run the following command dotnet lambda deploy-function fwa-workflow-engine -c Release -fd "fwa workflow support" -fn fwa-workflow-engine -fh HMIFlexEngineLambda::HMIFlexEngineLambda.Function::FunctionHandler -frun dotnetcore2.1 -frole arn:aws:iam::###account###:role/hmiflex-dev-engline-lambda-execution-role -framework netcoreapp2.1 -fms 512 -ft 120 -tm PassThrough -fsub subnet-0be4c3d9057887d4b ,subnet-0fc3aa8492b70954f -fsec sg-094d753b6e6525778 and it fails with Error updating code for Lambda function: The runtime parameter of dotnetcore2.0 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (dotnetcore2.1) while creating or updating functions. I can manually deploy from Visual Studio without problems. Just not from CodeBuild.

jfeyers avatar Oct 01 '19 15:10 jfeyers

Hi @TommyN,

Good afternoon.

I was going through the issue backlog and came across this one. Please let me know if this is still an issue or if this could be closed.

Thanks, Ashish

ashishdhingra avatar Sep 11 '20 22:09 ashishdhingra

I'll close if for now @ashishdhingra. I'll try to keep the issue in mind for when 2.1 is deprecated and retest.

TommyN avatar Sep 14 '20 08:09 TommyN

Well, now I'm having this problem with dotnet2.1. I have the same error using Code Build to update the lambdas...

"An error occurred (InvalidParameterValueException) when calling the UpdateFunctionCode operation: The runtime parameter of dotnetcore2.1 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (dotnet6) while creating or updating functions."

ibelchiorbjss avatar May 10 '22 11:05 ibelchiorbjss

Sorry @ibelchiorbjss but Microsoft deprecated .NET Core 2.1 back in August and it looks like last month Lambda entered phase 2 of their deprecation policy for .NET Core 2.1 which no longer allows create or updates of 2.1 functions. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html#runtime-support-policy

normj avatar May 10 '22 21:05 normj

@normj I can confirm that I'm seeing the same issue as originally reported, but now when trying to upgrade a netcoreapp2.1 project to net6.0.

c:\development\GitHub\...\>dotnet lambda deploy-function:

C:\development\GitHub\......>dotnet lambda deploy-function
Amazon Lambda Tools for .NET Core applications (5.4.1)
Project Home: https://github.com/aws/aws-extensions-for-dotnet-cli, https://github.com/aws/aws-lambda-dotnet

Executing publish command
Deleted previous publish folder
... invoking 'dotnet publish', working folder 'C:\development\GitHub\...\bin\Release\net6.0\publish'
... dotnet publish --output "C:\development\GitHub\...\bin\Release\net6.0\publish" --configuration "Release" --framework "net6.0" /p:GenerateRuntimeConfigurationFiles=true --runtime linux-x64 --self-contained false
... publish: Microsoft (R) Build Engine version 17.1.1+a02f73656 for .NET
... publish: Copyright (C) Microsoft Corporation. All rights reserved.
... publish:   Determining projects to restore...
... publish:   All projects are up-to-date for restore.
... publish:   Our.AWS -> C:\development\GitHub\...\bin\Release\netstandard2.0\Our.AWS.dll
... publish:   TvSchedulesConcatenator -> C:\development\GitHub\...\bin\Release\net6.0\linux-x64\TvSchedulesConcatenator.dll
... publish:   TvSchedulesConcatenator -> C:\development\GitHub\...\bin\Release\net6.0\publish\
Zipping publish folder C:\development\GitHub\...\bin\Release\net6.0\publish to C:\development\GitHub\...\bin\Release\net6.0\TvSchedulesConcatenator.zip
... zipping: Amazon.Lambda.APIGatewayEvents.dll
... zipping: Amazon.Lambda.ApplicationLoadBalancerEvents.dll
... zipping: Amazon.Lambda.Core.dll
... zipping: Amazon.Lambda.Serialization.Json.dll
... zipping: AWSSDK.Core.dll
... zipping: AWSSDK.MediaConvert.dll
... zipping: AWSSDK.S3.dll
... zipping: AWSSDK.SQS.dll
... zipping: Our.AWS.dll
... zipping: Our.AWS.pdb
... zipping: Newtonsoft.Json.dll
... zipping: TvSchedulesConcatenator.deps.json
... zipping: TvSchedulesConcatenator.dll
... zipping: TvSchedulesConcatenator.pdb
... zipping: TvSchedulesConcatenator.runtimeconfig.json
Created publish archive (C:\development\GitHub\...\bin\Release\net6.0\TvSchedulesConcatenator.zip).
Updating code for existing function
Error updating code for Lambda function: The runtime parameter of dotnetcore2.1 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (dotnet6) while creating or updating functions.

aws-lambda-tools-defaults.json

  "profile": "default",
  "region": "eu-west-1",
  "configuration": "Release",
  "framework": "net6.0",
  "function-runtime": "dotnet6",
  "function-memory-size": 512,
  "function-timeout": 8,
  "function-handler": "<snip>",
  "function-name": "<snip>",
  "function-role": "<snip>"

TommyN avatar May 23 '22 11:05 TommyN

Ah, I think I understand what is happening now. When deploying new code the tool makes two Lambda service calls. First to update the code and then second to update the function's configuration including the runtime. Since the runtime isn't updated to .NET 6 till the second service call the call to update the function's code fails due to the state of .NET Core 2.1 deprecation status. Let me do some research on the impact of switching the order of those 2 service calls.

normj avatar May 25 '22 00:05 normj

@TommyN Please confirm if this is still an issue.

ashishdhingra avatar Oct 12 '22 20:10 ashishdhingra

@ashishdhingra, our functions have already been updated so it's not possible for me to test again. Did @normj switch the 2 service calls in a recent release? If not, this will still be an issue for people upgrading from an EOL version.

TommyN avatar Oct 12 '22 20:10 TommyN

@ashishdhingra, our functions have already been updated so it's not possible for me to test again. Did @normj switch the 2 service calls in a recent release? If not, this will still be an issue for people upgrading from an EOL version.

Need to check with @normj if this is fixed.

ashishdhingra avatar Dec 24 '22 00:12 ashishdhingra

This issue was fixed in Amazon.Lambda.Tools (5.6.4). Kindly validate from your end and please reopen this issue if you are still facing issues.

philasmar avatar Apr 18 '23 14:04 philasmar

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

github-actions[bot] avatar Apr 18 '23 14:04 github-actions[bot]