search

serverless-nextjs / serverless-next.js

⚡ Deploy your Next.js apps on AWS Lambda@Edge via Serverless Components
MIT License
4.47k stars 457 forks source link

Please upgrade to 3.5.3 or later or your deployments may start breaking #2089

Open dphang opened 2 years ago

dphang commented 2 years ago

See: https://github.com/serverless-nextjs/serverless-next.js/issues/2070 Due to Lambda state expansion: https://aws.amazon.com/blogs/compute/coming-soon-expansion-of-aws-lambda-states-to-all-functions/, old versions may fail to deploy as the Lambda state is not waited on for it to be ready. This would mainly apply if you are using the serverless components deployer.

Please upgrade to 3.5.3 or later (which has a fix to address this) to avoid potential deploy issues that could cause your app to fail. I believe it should be compatible with Next.js 9/10 still (but I recommend you try to upgrade if possible), but if you have problems using it, please let me know and i can try to address it.

dphang commented 2 years ago

Also, do let us know if there's any incompatibility with the new version (e.g you are using an old next.js version and somehow something breaks) I could release a patch for an older version if there's enough need for it (maybe 1.18 or 1.19 etc.)

Alternatively, a workaround is to use an old version to build the app artifacts while using a newer version to deploy.

rkgomekar commented 2 years ago

@dphang - We were using the version 1.9.5 and after upgrading to 3.5.3, we have started getting 502 error from Cloudfront for our app. Could you provide patch for this version?

Alternatively, could you provide some steps or a link to use an old version to build the app artifacts while using a newer version to deploy.

dphang commented 2 years ago

Sure I can try to patch a couple select versions later today though I think that one you are using is pretty old at this point.

Otherwise you can use workaround I mentioned, or if can't wait I believe you might be able to use patch-package to manually patch the aws-lambda package as well.

dphang commented 2 years ago

Published @sls-next/serverless-component@1.18.1-patch.2 which patches 1.18 with the fix. I hope this should work as well for most if you cannot upgrade yet.

Thanks to Fernando Dingler for helping provide the patch.

dphang commented 2 years ago

@rkgomekar I couldn't find version 1.9.5 in npm here under our versions (https://www.npmjs.com/package/@sls-next/serverless-component), can you point which one you are using (link to the npm package url or if you know what git commit it is). If it's the old plugin it might already be deprecated so would be hard to patch. Otherwise you could also try version 1.18.1-patch.2 above

lazarofrancoe commented 2 years ago

Here we were deploying using 1.19.0-alpha.30 for a year now smoothly, upgraded to 3.6.0 because our deployment suddenly broke due to lambda state expansion, but now we're getting the 'RequestEntityTooLargeException' error with 3.6.0 (never got this error before), any clue? I've tried the following:

1.18.1-patch.2 Deployment ok, but error from cloudfront while getting images 1.19.0-alpha.30 ResourceConflictException (ORIGINAL) 1.19.0-alpha.42 ResourceConflictException 3.6.0 RequestEntityTooLargeException 3.7.0-alpha.1 RequestEntityTooLargeException

dphang commented 2 years ago

@lazarofrancoe where are you getting the RequestEntityTooLargeException? Seems it could happen when updating the function or uploading the code per here: https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-deployment.html. How large is your code package you are trying to upload, are you close to the limit (there may have been slight increases in our handler sizes in 3.60 etc due to new features)?

Anyway, I'll patch a couple more versions later today to get more coverage.

lazarofrancoe commented 2 years ago

The exception raises when serverless invokes the CreateFunction operation for the regeneration-lambda lambda function, which was not generated in 1.19.0-alpha.30. Is there any way to disable ISR?

dphang commented 2 years ago

Strange, it should not be trying to create the regeneration-lambda function if you aren't using ISR (e.g added revalidate to your pages)... not quite sure what's going on there

Anyway I've also published a patch on top of 1.19: @sls-next/serverless-component@1.19.1-patch.1

lazarofrancoe commented 2 years ago

Not sure either, but the resulting regeneration-lambda was about ~300mb! I'll have to investigate if we want to use ISR in the futures though. Anyway, successfully applied @sls-next/serverless-component@1.19.1-patch.1 and deployed on AWS, thanks! You should enable tipping here on Github so I can grab you a coffee.

dphang commented 2 years ago

That's strange, there might be some other issue, if you have a chance later it'll be helpful to post the content of the regeneration-lambda folder in another issue so we can see what's up (although not sure when I can look at it).

There's no tipping enabled right now but feel free to contribute to the project on opencollective if you want: https://opencollective.com/serverless-nextjs-plugin, it's used to directly pay costs like AWS costs used for CI, etc :). Thanks for your support!

smasilamani-cfins commented 2 years ago

@dphang

@rkgomekar used to work with us on this and we still get 502 error and upon further investigation we figured out that we hit the edge lambda payload limit size of 1MB after we upgraded to newer version. We never had this issue with the older versions. Please advise

dphang commented 2 years ago

@dphang

@rkgomekar used to work with us on this and we still get 502 error and upon further investigation we figured out that we hit the edge lambda payload limit size of 1MB after we upgraded to newer version. We never had this issue with the older versions. Please advise

Could you create a repro and share it if possible? What type of page is it? Yes 502 is usually due to lambda response size limit, if it's hit that's a lambda@edge limitation. But without more details I'm not sure what's going on. Usually I've seen that for users on API pages where more than 1 MB data is requested.

dphang commented 2 years ago

I have published the patched version here for 1.9.5 (it's long deprecated so won't get any support beyond fixing the lambda deployment issue): https://www.npmjs.com/package/@sls-next/serverless-next-js-patch

it basically just uses the latest @sls-next/aws-lambda package which was forked and has the fixes for Lambda state.

https://www.npmjs.com/package/@sls-next/serverless-next-js-patch

@sls-next/serverless-next-js-patch@1.9.5-patch doesn't set runtime, so it uses Node.js 10.x which actually you cannot create anymore new Lambdas. Hence I needed to set runtime to 14.x below to actually test it. @sls-next/serverless-next-js-patch@1.9.5-patch.1 sets runtime to Node.js 14.x

I verified the 1.9.5-patch.1 could deploy fine (can't verify 1.9.5 since I can't create new Node.js 10 functions). Note that in 1.9.5 runtime was also hardcoded to node 10.x so assuming 1.9.5-patch should work fine for you if you already have a node 10.x function.