ky-universal fetch leads to body timeout errors
See original GitHub issueBug report
I use ky-universal
with Next.js to handle all my API calls, and I use ky
’s hooks (middleware for APIs) to do things like logging, handling cookies, etc.
The library had a long-standing bug with timeout errors on large response bodies, and it was recently fixed when they switched their node-fetch
dependency to 3.0.0-beta.6
. Note that these are not actually timeouts from the API itself, but timeouts while trying to consume the response stream and parsing it as JSON. The linked PR was supposed to fix these issues (similar to mine) —
- https://github.com/sindresorhus/ky-universal/issues/8
- https://github.com/sindresorhus/ky/issues/135
- https://github.com/sindresorhus/ky-universal/issues/18
- https://github.com/sindresorhus/ky-universal/issues/15
After this change, I’d expected my hooks to work again, but I’m still getting the same errors —
FetchError: Response timeout while trying to fetch https://my-api.com/my-api (over 30000ms)
at Timeout._onTimeout (/my-project/node_modules/next/dist/compiled/node-fetch/index.js:1:134853)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7) {
type: 'body-timeout'
}
This leads me to believe Next.js’s own version of node-fetch
is shadowing the one that ky-universal
should use.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
- See https://github.com/paambaati/ky-body-timeout-repro
- Use https://github.com/paambaati/ky-body-timeout-repro/blob/234f5b9ca9af5de576b1b86ead650b29daaef66c/index.js#L28 and the associated
api()
method in a Next.js API route withky-universal
dependency set to version0.7.0
- this version includes the fix for timeouts. - Hit the Next.js API route and watch it timeout for responses roughly over 50 KB in size.
Expected behavior
- Should not error if we’re using the latest version of
ky-universal
. - Should prefer
ky-universal
’s node-fetch over Next.js’s own.
System information
- OS: macOS Mojave 10.14.6
- Browser Chrome & Firefox
- Version of Next.js: 9.4.4
- Version of Node.js: 14.1.0
Additional context
Somewhat related — https://github.com/vercel/next.js/issues/12761
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:15 (8 by maintainers)
Top GitHub Comments
Hi all, Ky maintainer here! Happy to help with this.
Just to make sure we’re on the same page, Next has not yet released a version that uses
ky-unversal
v0.7.0 and it hasn’t updated its ownnode-fetch
dependecy to avoid theclone()
bug either. What are you doing to ensure the correct versions are being used?Also, could someone enlighten me as to why Next uses
node-fetch
andky-universal
? The main purpose ofky-universal
is that it ships polyfills for web standard APIs that some environments are missing (mainly Node). If you’re shipping your own polyfills, for whatever reason, then you should be able to useky
by itself withoutky-universal
.I’m assuming that Next attaches its
node-fetch
dependency to the global scope, as that should be the only thing that would cause the updatednode-fetch
version withinky-universal
to be ignored. If that’s the case, then it’s behaving as intended because we don’t wantky-universal
to overwrite any existingfetch
implementation. It only uses its own if it has to. We could changeky-universal
so that it has a stronger bias towards its own fetch implementation, but then we’d have the opposite problem, ifky-universal
had outdated dependencies, then it would be a pain. Given thatfetch
ought to be part of the environment in the first place, I personally think the “use our own as plan B” approach is the right way.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.