Description
Link to the code that reproduces this issue
https://github.com/eebirke/request-timeout-repro
To Reproduce
- Start the app (either dev or build & start).
- Throttle network speed in dev tools to 1 Mbps or lower, or Fast 3G or slower.
- Select a sufficiently large file (I'm testing with 110 MB, but 50 MB should be fine).
- 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