Amplify-cli: How to update nested cloudformation stack in AWS Amplify

[boricic]

Within my AWS Amplify application I started receiving emails about Node.js 8.10 end-of-life, urging me to change to Node.js 10.x.

I was able to change versions of functions that I've created by amplify add function by simply editing generated CloudFormation template. However, when I tried doing so for resources that Amplify generated for me, I got No Change upon running amplify status and subsequent amplify push did nothing.

To be more specific, the function that I'm unable to change is located in nested-cloudformation-stack.yml (within amplify/backend/awscloudformation/). The function is called UpdateRolesWithIDPFunction, which presumably has something to do with Cognito setup.

Amplify CLI Version

I'm using 3.17 version of Amplify CLI

[yuth]

@boricic thank you for reaching out. Amplify CLI generates the nested-cloudformation-stack.yml before doing a push and any changes made to this file will be overwritten. We have a task in our backlog to update the custom resources to nodejs10.x and we will update migration documentation once the task is complete

[rekursief]

I also encountered the same issue with an Amplify app, I found a documentation page handling going from nodejs 6.10 to 8.10 (https://aws-amplify.github.io/docs/cli/lambda-node-version-update) which gave me some insights on how to respond to these emails I received from AWS. But as @boricic mentioned the UpdateRolesWithIDPFunction seems uncovered within de codebase.
@yuth Is your advice to not update all these Amplify CLI generate lambda functions or just the one mentioned above?

[nicholasgriffen]

The auto-magically generated lambdas, e.g. for Cognito, do not support node 10 yet. Check out this issue for more details: https://github.com/aws-amplify/amplify-cli/issues/2617

[kaustavghosh06]

This is a duplicate of #2617
Closing this as a duplicate

[houmark]

@kaustavghosh06 I just updated to Amplify 4.11 and the CLI offered two functions to be updated to node.js 10.x. I ran this migration and pushed without issues.

I then proceeded to check the function versions in the Lambda console directly and noticed the UpdateRolesWithIDPFunction is still running node.js 8, even though the nested-cloudformation-stack.yml file has node has "Runtime": "nodejs10.x",.

How do I trigger this function to be updated in the cloud as well?

[UnleashedMind]

The Lambda Console sometimes does not update promptly.
Did you notice that the custom resource update of function through CloudFormation as "Complete"?

[houmark]

It's been 12 hours, so :)

I'm not sure what you mean by the second statement exactly, sorry.

[houmark]

I now did a search and opened amplify/backend/auth/redacted-cloudformation-template.yml because I found the migration documentation where it explains that const response = require('cfn-response'); must be replaced with const response = require('./cfn-response'); and in this yml file, that was not replaced, even though the nodejs version was updated to 10.x (maybe you'd want to improve the migration script to also do that change for this file?).

That now triggers an updated Auth category in the CLI, so I am assuming it will also update to nodejs 10.x in the same run.

[UnleashedMind]

the './cfn-response' replacement is only for the interactions category, not for the auth triggers

[houmark]

Okay, that makes little sense to me, when looking at the source code generated directly in the Lambda function, I have the following (screenshot):
https://share.getcloudapp.com/2NurvwDp

Wouldn't that include the npm package cfn-response over the local file?

[UnleashedMind]

Yes, sibling module reference by nodejs require needs to use a path, instead of a just a module name. This could be a Lambda server side issue, we are investigating now.

[UnleashedMind]

on your previous remarks "I'm not sure what you mean by the second statement exactly, sorry."

UpdateRolesWithIDPFunction is a resource of type "AWS::Lambda::Function", when you push, that resource is updated because its Runtime property has been updated.

Did you see that update in the "Complete" status?

[houmark]

Yes, sibling module reference by nodejs require needs to use a path, instead of a just a module name. This could be a Lambda server side issue, we are investigating now.

So is that confirming that I do have to change cfn-response to ./cfn-response for this function?

Did you see that update in the "Complete" status?

I honestly do not recall and I am unable to scroll back to see the changes done. But my best guess is that it did not.

After manually having done changes to the yml file I now have the Auth cateory to be updated, but I did not push yet as I am confused about if I need to change the cfn-response path or not — please confirm.

[nicholasgriffen]

@houmark you can check your stack statuses in the AWS console here: (
replace us-west-2 with your region )
https://us-west-2.console.aws.amazon.com/cloudformation/home?region=us-west-2#/stacks?

On Tue, Jan 7, 2020 at 5:28 PM houmark [e-mail] wrote:

Yes, sibling module reference by nodejs require needs to use a path,
instead of a just a module name. This could be a Lambda server side issue,
we are investigating now.

So is that confirming that I do have to change cfn-response to
./cfn-response for this function?

Did you see that update in the "Complete" status?

I honestly do not recall and I am unable to scroll back to see the changes
done. But my best guess is that it did not.

After manually having done changes to the yml file I now have the Auth
cateory to be updated, but I did not push yet as I am confused about if I
need to change the cfn-response path or not — please confirm.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aws-amplify/amplify-cli/issues/2745?email_source=notifications&email_token=AEFZCQZXWUVKZR6A35J5LATQ4UM3PA5CNFSM4JNRQT52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIKYN3A#issuecomment-571836140,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEFZCQ2JVOZ5BSH5WSTBLJ3Q4UM3PANCNFSM4JNRQT5Q
.

[houmark]

Oh, if you are referring to UPDATE_COMPLETE for the push then yes, the consecutive push was UPDATE_COMPLETE.

[kaustavghosh06]

@houmark you do not need to change the in-line Lambda functions in the cloudformation templates. Cloudformation packages up the cfn-response node module when used in-line in the template and makes it available for the lambda package to consume (that's not the same case for other lambda functions).
Also the "UpdateRolesWithIDPFunction" resource in the nested-cloudfomration file is generated at run-time on every amplify push (and is also not checked into source control), so on your next amplify push with the latest version of the CLI, you'll see the runtime of that function to Node 10.x.
Did you push the changes to your test environment as recommended and was your push successful?

[houmark]

I'm confused now. I got an email notification which mentioned I do need to change it. What's the final verdict?

[kaustavghosh06]

@houmark Are you sure the updateFunction resource is for the same environment that you pushed to successfully? As I said above the CLI would modify the updateFunction resource at runtime - during the next amplify push and update it with Node 10.x.

[houmark]

Yes, the first push after updating/migration to 4.11 did not push the updated runtime, that I am sure of. After manually editing the yml file due to the cfn-response (and my editor removing trailing whitespace in that file), it did show up as an update and did update to node 10.x on the next push.

I'm still confused if cfn-response needs to be ./cfn-response or cfn-response in that inline function. I have a sibling file called cfn-response.js in the same folder, not sure why, this may be an old leftover as this function was added some 6 months ago.

[kaustavghosh06]

@houmark Does the cfn-response file exists in your local filesystem or do you see it just in the AWS Lambda console?

[kaustavghosh06]

If you were to successfully deploy - then you don't need to modify it - if the Lambda is defined inside the Cloudformation template (which is your case), you don't need to worry about the change from cfn-response to be ./cfn-response.