Internal server error with standalone output

[CobyPear]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.6.0: Thu Mar  9 20:12:21 PST 2023; root:xnu-8020.240.18.700.8~1/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.16.0
      npm: 9.5.1
      Yarn: 1.22.17
      pnpm: 8.1.0
    Relevant packages:
      next: 13.4.4-canary.8
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.5

Which area(s) of Next.js are affected? (leave empty if unsure)

Routing (next/router, next/navigation, next/link), Standalone mode (output: "standalone")

Link to the code that reproduces this issue or a replay of the bug

https://github.com/CobyPear/repro-no-router/tree/use-latest-canaries

To Reproduce

1. Clone the reproduction repo (use-latest-canaries branch)
2. cd into the clone
3. npm i && npm run build && npm start
4. got to localhost:3000

Describe the Bug

Originally reported here and was asked to make a new issue

Current behavior: Internal Server Error on initial load.

Terminal shows the following:

Error: connect ECONNREFUSED 127.0.0.1:63712
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
  errno: -61,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 63712
}

Expected Behavior

The application starts without errors. Navigation with the Link component works, hooks like useState are available on the client side and are working.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[pc-erin]

I'm seeing this as well. Is your site image heavy, and are you using sharp for production image optimization?

After monitoring the RAM usage of my container, it looks like what's happening is that if someone requests a bunch of images at once, next sends those resize requests (unthrottled) to sharp, which uses up RAM until it runs out, then crashes. Next doesn't handle sharp crashing and restart it, but crashes itself when it's requests to sharp go unanswered.

This can be replicated by putting a dozen or so large images (like 2000w at least) onto the index page, turning on image optimization, then running the server in a container with RAM limited to 500MB. Access the index page and the first few may load before the server starts returning 500 errors.

Disabling image optimization or removing the sharp dependency will solve this, but then all images will be served at their original size, making srcsets pointless.

My current workaround is to use a CDN that does image resizing for us.

Ideally next would automatically throttle image requests so that anyone using optimization in production won't have their site die if someone requests too many images at once, as that seems like a DoS vulnerability of sorts.

I believe memory pressure can be monitored by reading /sys/fs/cgroup/memory.pressure. This works both inside and outside a container. If it polls this file and throttles resize requests when pressure increases too much, that would likely solve the problem. It's not necessarily a trivial solution, and almost certainly not a cross-platform one.

[CobyPear]

After monitoring the RAM usage of my container, it looks like what's happening is that if someone requests a bunch of images at once, next sends those resize requests (unthrottled) to sharp, which uses up RAM until it runs out, then crashes. Next doesn't handle sharp crashing and restart it, but crashes itself when it's requests to sharp go unanswered.

That is really interesting. I haven't tested the reproduction lately but our deployed app DOES use sharp; not a ton of images tho. Some of the images have been failing to load on the first page load, like 1 or 2 out of 10, but refreshing will get them to show up.

[balazsorban44]

This seems to have been fixed because I could not reproduce it anymore. Make sure to upgrade if you are still seeing this. There is a slightly similar issue currently being tracked at #51684, you can follow that if you think it's related.

If you are still seeing this using the latest version of Next.js, please open a new issue, thanks!

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.