My deployment fails with the below message:
‘The function “___NETLIFY-ODB-HANDLER” is larger than the 50MB limit.’
This is a NextJs site.
Sitename: ‘rad-cajeta-9ddd20.netlify.app’.
Site ID: ‘32356854-6eae-4698-b0e3-487556f60f69’
The build process completes fine, but deployment fails.
Nothing changed on the site apart from a number of pages. I suspect this is due to the large number of pre-rendered pages.
fallback: “blocking” from getStaticPaths is used as per Netlify Docs.
2:50:38 AM: Next.js cache saved.
2:50:38 AM: The function zip …/…/…/tmp/zisi-64bc857274de084bac8c542b/___netlify-odb-handler.zip size is 55.5 MB, which is larger than the recommended maximum size of 52.4 MB.
2:50:38 AM: This will fail the build if the unzipped size is bigger than the maximum size of 262 MB.
2:50:38 AM: There are a few reasons this could happen. You may have accidentally bundled a large dependency, or you might have a
2:50:38 AM: large number of pre-rendered pages included.
What do you mean no luck? It says exactly what you need to do to reduce the number of pre-rendered pages. Now if you mean you don’t wish to reduce the number of pre-rendered pages, that’s a different story.
No. It’s imposed by AWS, not by Netlify.
Not possible. It would be in the future, but not right now.
I have already set fallback: “blocking” from getStaticPaths is used as per Netlify Docs.
I can certainly use Static Site Generation which works perfectly. But there is a little problem. If I have 400+ product pages, with the possibility of text and images changing weekly, etc. By changing a single product I would need to regenerate all pages (the whole site) every single time.
In this case, Incremental Static Generation ISR is ideal (with a revalidation option). Where I can simply regenerate a single product page on Demain. But this will cause the build to fail.
I can probably use Server Side Rendering CSR, but this is a waste of resources :(.
As I mentioned, it’s currently a platform limitation. You’re not the only one running into this, so we have a more robust and a permanent solution in the works, which we aere hoping to ship in Q3. If all goes well, you should not be having this issue in the coming months, but till then, there’s no better solution.
My Next.js application has been building just fine with “satisfies” in it for months, and since yesterday it is breaking on every build? Something must have changed as I’ve reverted any dependency change I made and still keep getting the same errors…
I cannot share my repo, I can give you the site name: app.leadbox.be
I’ve since yesterday removed all uses of “satisfies” as I need to be able to deploy new versions.
Only the staging environment has changed, production still has the satisfies keywords in it.
Based on your deploy logs: Deploy details | Deploys | leadbox | Netlify , it simply seems you either need to disable some ESLint rules, or write your code in a way that ESLint won’t complain.