Skip to content

Unexpected request close/abort after 5 minutes #74992

Open
@eebirke

Description

Link to the code that reproduces this issue

https://github.com/eebirke/request-timeout-repro

To Reproduce

  1. Start the app (either dev or build & start).
  2. Throttle network speed in dev tools to 1 Mbps or lower, or Fast 3G or slower.
  3. Select a sufficiently large file (I'm testing with 110 MB, but 50 MB should be fine).
  4. After 5-5.5 minutes the request fails (error is displayed in both the server console and in the app - fails with ECONNRESET on the server).

(Example adapted from a file streaming case where client streams files to the API, which in turn streams it into S3).

Current vs. Expected behavior

It seems unexpected that there is a 5 minute hard-limit after which requests are stopped with no clear reason, with seemingly no way to override the behavior.
After a few days of debugging I figured out that the Node Server instance associated with the requests had default values for requestTimeout that are not directly configurable from what I can see.

After making this change to start-server.js in node_modules/next/dist/server/lib I could get the upload to run for an hour.

+    const ONE_HOUR = 3600000;
    const server = selfSignedCertificate ? _https.default.createServer({
        key: _fs.default.readFileSync(selfSignedCertificate.key),
        cert: _fs.default.readFileSync(selfSignedCertificate.cert),
+       requestTimeout: ONE_HOUR
-    }, requestListener) : _http.default.createServer(requestListener);
+    }, requestListener) : _http.default.createServer({requestTimeout: ONE_HOUR}, requestListener);

I suppose a quick fix on our end is using the custom server setup and supplying our own node Server instance, though I am not entirely sure which of Next's features we'd lose out on in that case.

I could not find any reference to timeout issues in the docs.

I'm guessing that increasing the requestTimeout across all requests could create issues when you get many concurrent slow connections, so are there any other ways of doing this (except splitting the original upload into multiple, chunked upload requests)?

Should Next.js highlight these limitations, or should it ideally be configurable?

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.2.0: Fri Dec  6 19:02:12 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6031
  Available memory (MB): 36864
  Available CPU cores: 14
Binaries:
  Node: 22.6.0
  npm: 10.8.2
  Yarn: N/A
  pnpm: 9.15.0
Relevant Packages:
  next: 15.1.4 // Latest available version is detected (15.1.4).
  eslint-config-next: 15.1.4
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Runtime

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

Additional context

This happens on both Next 14 and 15, and across Node 18, 20 and 22.
Have tested this on Firefox, Chrome and Safari on MacOS, as well as Chrome on Windows.

Might be related to discussion thread on socket abort issues, but not sure #60148

Metadata

Assignees

No one assigned

    Labels

    RuntimeRelated to Node.js or Edge Runtime with Next.js.

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions