Not compatible with nextJs > 10

[Friis1978]

Describe the bug

When updating to Next.js > v.10.0.0, we could not deploy the code in github actions.
If someone else have seen something similar, we really want your comments how to resolve this issue.

Actual behavior

error:
AccessDenied: User: arn:aws:iam::***:user/github-cli is not authorized to perform: iam:GetRole on resource: role 7kv1mz9-eng6t1i
at Request.extractError (/home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/protocol/query.js:50:29)
at Request.callListeners (/home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
at Request.emit (/home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
at Request.emit (/home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/request.js:688:14)
at Request.transition (/home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/request.js:22:10)
at AcceptorStateMachine.runTo (/home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/state_machine.js:14:12)
at /home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/state_machine.js:26:10
at Request. (/home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/request.js:38:9)
at Request. (/home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/request.js:690:12)
at Request.callListeners (/home/runner/.serverless/components/registry/npm/@sls-next/serverless-component@1.19.0-alpha.30/node_modules/aws-sdk/lib/sequential_executor.js:116:18) {
code: 'AccessDenied',
time: 2021-04-28T18:03:15.068Z,
requestId: '1c0a6b75-6e7e-43f6-ba97-68ad34b91f5a',
statusCode: 403,
retryable: false,
retryDelay: 20.23841852847137

Expected behavior

To deploy our code

Steps to reproduce

Upgrade your Next.js project to version > 10.0.0

Screenshots/Code/Logs

Versions

• OS/Environment:
• @sls-next/serverless-component version: 1.19.0-alpha.51
• Next.js version: 10.2.0

Additional context

What we are trying a achieve is actually to be able to use Sentry, but this is dependant of using Next.js > 10.

The funny thing is that 'role 7kv1mz9-eng6t1i' not exists at all in our roles, as we use our own custom roles & know what their names are, and this is not one of them.

[elbasan]

I'm having the same issue

[Friis1978]

@elbasan did you find any links about how to fix it?

[dphang]

I am not sure about this, it does seems like a permission issue on AWS... it seems like a mismatch between what the deployment expects your function name to be (auto-generated) vs. the actual function names. Maybe can you check .serverless_nextjs directory and check so see all the functions, buckets, etc are as expected?

Also does it always repro on a new project? Without that it might be hard to debug the issue. As an aside, I do now need to update the e2e tests to test on latest version (10.2.0) since it's pinned to 10.0.x right now. I will check if there is any issue there and update back.

[Friis1978]

@dphang thanks, I will try to setup a whole new project, and see if that will work.

[suneg]

I believe I have the steps to reproduce the problem. The error is not exactly the same as stated above, but it appears to be the same underlying problem.

NextJS upgrade scenario: 9.5.5 -> 10.2.0
sls-next/serverless-component version: 1.19

1. Clone my small sample from this repo: https://github.com/suneg/serverless-next-issue-1030-repro
2. Run npx serverless -v (should complete without errors, but might require you to have an existing named role)
3. Upgrade next by running npm install next@10.2.0
4. Run npx serverless -v

Output:

...is not authorized to perform: lambda:GetFunctionConfiguration on resource: arn:aws:lambda:us-east-1:633235609130:function:yi0pvu-0387b2

Notice that it used an autogenerated function name, despite the function name is configured in serverless.yml. The permission error is a result of the IAM policy of the calling user, only having rights for the specific lambda resource mentioned in serverless.yml.

If you downgrade to 9.5.5, the deployment process starts working again.

[jvarho]

Notice that it used an autogenerated function name, despite the function name is configured in serverless.yml. The permission error is a result of the IAM policy of the calling user, only having rights for the specific lambda resource mentioned in serverless.yml.

If you downgrade to 9.5.5, the deployment process starts working again.

There is now a third lambda for images. If you define a name for imageLambda (see readme) which the role has access to you should be good?

[suneg]

Thanks for your input @jvarho

I was unable to repro on my small sample project, after I accidentally deployed it using AWS admin credentials. So I tried upgrading my "real" project instead. I added the imageLambda property, and that got me past the previous error. Now I was getting...

AccessDenied: User: arn:aws:iam::***:user/github-cli is not authorized to perform: iam:GetRole on resource: role 7kv1mz9-ntea2hu

I had already specified a named roleArn, so I didn't understand why it attempted to use a generated name.

Anyway, I upgraded my project from 1.19-alpha.30 to 1.19, and then it actually works! 😃

Does the custom lambda names have to be unique or can both apiLambda, defaultLambda and imageLambda share the same name? So far having the same name has worked fine for me.

[dphang]

Wondering if this can be closed right now if the original issue has been solved? @Friis1978

[Friis1978]

Seems like @suneg solved one of the issues, but im not sure the whole thing is solved.
@suneg can you explain the missing issues ?

[suneg]

I don't see any problem when using the latest 1.19 release, and using custom names for all three (default, api, and image) lambdas. I suggest closing this issue.