-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Frequent fetch() errors #458
Comments
So far I have tried:
With no change in behavior Not sure I have any other knobs to turn on my end... I will update to the latest https://github.com/nodejs/corepack/releases/tag/v0.27.0 and see if that helps, there are a few optimizations there that might help ( fix: download fewer metadata from npm registry #436 ) |
I still experience this issue with the newly released 0.27.0 |
I will be reverting to 0.24.0 (pre fetch() being used) for the time being :/ I wish I knew which one of these it was (probably?), but potentially if there was a way to set some of these timeouts that would be great.... |
#430 should start printing the |
Give me a few days to get back to you. I have been running 0.28.0 a lot to try and get the reason/cause and havent seen the issue at all since.... I will give it a few days and then I will step it back to 0.27.0 (would be wild if this made a difference looking at just the change related to clipanion.,...) or 0.26.0 just to confirm that the issue is still reproducible-ish on my setup. There is also a chance it was ISP related and is no longer a problem for me? Just wanted to confirm that I am on it to followup, but it will take some time to be deterministic/conclusive, but as of now on 0.28.0, things are looking better unfortunately? 😆 |
Don't really know what to make of it, I haven't had an issue since my previous posts. I switched to 0.27.0 for a bit and still didn't have an issue. This will just have to remain a mystery until someone else encounters issues and we now see the cause. For now I will stay on 0.28.0 or the latest and report back if anything ever happens |
FWIW I encountered this issue while executing GitHub actions on Node 16. Switching to Node 18 has resolved the issue. |
Saw a handful of CI jobs fail today, kind of a normal error when the system/server/network is overloaded a bit but still pretty inconvenient situation that is not currently overridable with ENV vars (for corepack to use when creating the undici fetch request, agent, and dispatcher) or anything currently I don't think. For what it's worth, I experienced this back when I switched from axios -> undici fetch on several of my projects due to axios not having any timeouts as default, and fetch having sane defaults. #365 might have experienced a similar change from https -> undici fetch with timeouts changing significantly If I had my choice, I would override the defaults to just double them (since it is just CI for me) and move on for now. I don't think changing the corepack default fetch parameters makes sense for everyone/this repository/corepack itself for this particular situation. Increasing them by default in corepack could be beneficial though without many downsides
|
It's work for me when using |
I am encountering this a LOT intermittently during CI for my projects. I can rerun CI and then it is all fine. I have looked at the troubleshooting referenced but I am not behind a proxy so am not really sure what else it could be. My suspicion is some sort of load oriented timeout or npm rate limiting per IP. It could be intermittent internet too, but without seeing the reason for the exception it is hard for me to debug effectively what is happening
I see there is some data in the throw here:
corepack/sources/httpUtils.ts
Lines 47 to 50 in 1423190
Is there a way for me to see the contents of this easily, I am not sure where it ends up. If not (I doubt this will be the answer) could we perhaps move the err to the text instead?
The text was updated successfully, but these errors were encountered: