I haven’t deployed to my next.js app in a while and all of a sudden I got an email about it being down. I’ve tried restarting the server, redeploying, and everything else I can but the build still fails with:
Jul 12 02:14:54 AM gzip: stdin: unexpected end of file
Jul 12 02:14:54 AM tar: Unexpected EOF in archive
Jul 12 02:14:54 AM tar: Unexpected EOF in archive
Jul 12 02:14:54 AM tar: Error is not recoverable: exiting now
Jul 12 02:14:54 AM chmod: cannot access '/opt/render/project/nodes/node-20.3.0/bin/*': No such file or directory
It seem like it’s suddenly unable to use node 20.3.0.
I also seem to be getting this:
error eslint-import-resolver-typescript@3.5.5: The engine "node" is incompatible with this module. Expected version "^14.18.0 || >=16.0.0". Got "14.17.0"
We have observed an issue in NextJS services, particularly in version 13.4.x, where it listens on multiple ports. This has caused problems with our ability to detect if your service is live on Render, as we connect to the ports opened by your service.
To resolve this issue, you can consider downgrading NextJS to version 13.3.x. Alternatively, as a workaround on Render, you can set the PORT environment variable to 10000. This will ensure that we only use port 10000 to check if your service is live. These steps should help address the problem you’re facing.
Thanks for your reply. I tried both steps mentioned and none of them seemed to address my problem. I had noticed that in this page Setting Your Node.js Version | Render Docs , it says render defaults to 14.7.0 for node.js and it offers ways to change that version. One of which was adding a .node-version. I have one of these for 20.3.0 and I could see it during the logs that it shows
Using Node version 20.3.0 via /opt/render/project/src/.node-version
However, it seem like it still ends up using that 14.7.0 or maybe that dependency is somehow initialized before the new node version is set?
Noticed this issue as well. Am trying the PORT: 10000 workaround and will follow up if that does not resolve.
FWIW, my first deployment with that new env var set was much faster than previous ones. Prior to that, I would regularly see deploys hang or take longer than expected. Presumably that was due to the liveness detection Jeremy mentioned.
I decided to create a new node.js service and point my domain name to that one instead and while that isn’t exactly a solution to the main problem, it’s resolved my issue for now.