[Bug?]: Getting a HTTP 500 error when trying to download Yarn from GitHub Workflow

[zac-hsone]

Self-service

• [ ] I'd be willing to implement a fix

Describe the bug

Whenever our GitHub actions try to download Yarn we come up against this error:

Error: Server answered with HTTP 500 when performing the request to https://repo.yarnpkg.com/4.10.3/packages/yarnpkg-cli/bin/yarn.js; for troubleshooting help, see https://github.com/nodejs/corepack#troubleshooting

To reproduce

Try to download use yarn from within a GitHub workflow

Environment

N/A

Additional context

No response

[ellharman]

Yep, seeing the same thing in our actions - seemingly no cause, just started flaking earlier today - wondering if it's a regression from this? https://github.com/nodejs/corepack/commit/cc840b2d232a29c225d2436d350640f0035ed28b

[arcanis]

From what I see our endpoints did return an elevated rate of 500s for a couple of hours, but I'm not sure why. Perhaps an incident on GH's side? Adding some logs to our workers to try and have a better error message should that happen again.

[zac-hsone]

Thanks so much for that. We're still seeing it on our side but I'm going to guess there's some caching going on somewhere?

It seems to work fine if I switch it from yarn set version berry to yarn set version 4.10.2

[arcanis]

I'm surprised a 500 would be cached, but from our logs the last 500 was triggered at 15:52 UTC.

I know we also sometimes have weird 504s, I have an open ticket with Cloudflare to try and figure out where that might come from, but that seems a different issue (those 500s came from the workers themselves).

[montyc1999]

I had a few cases today where corepack enable; yarn appeared to download an empty file from https://repo.yarnpkg.com/<version>/packages/yarnpkg-cli/bin/yarn.js, after which yarn any-command would exit 0 without any output.

edit: I didn't have a sha in my package.json's packageManager field. Hypothetically, a sha would have prevented this case.

[arcanis]

GitHub had a big incident today, although corepack shouldn't cache errors

[oskarols]

For anyone landing here, there's a big ongoing issue with Cloudflare that is likely causing issues with this today. https://www.cloudflarestatus.com/

[cwdx]

Confirming this issue is happening again right now (November 18, 2025 13:23 UTC) with Yarn 4.4.0.

All of our GitHub Actions workflows are failing with:

Internal Error: Server answered with HTTP 500 when performing the request to 
https://repo.yarnpkg.com/4.4.0/packages/yarnpkg-cli/bin/yarn.js

Both yarnpkg.com and repo.yarnpkg.com are returning HTTP 500 errors through Cloudflare's edge servers.

As mentioned in the previous comment, this appears to be related to the ongoing Cloudflare global network incident: https://www.cloudflarestatus.com/

Cloudflare is reporting: "Cloudflare is experiencing an internal service degradation. Some services may be intermittently impacted."

[ellharman]

We worked round this by using corepack hydrate with corepack.tgz, which skips the external dep, in case anyone is looking for a way to avoid this in future

[jsk95]

Also faced Error: Server answered with HTTP 500 when performing the request to https://repo.yarnpkg.com/4.11.0/packages/yarnpkg-cli/bin/yarn.js; for troubleshooting help, see https://github.com/nodejs/corepack#troubleshooting on repeated re-runs today running on Bitbucket build agents.

The package was available on local but not through our Bitbucket build agents, likely indicating some problems with specific Cloudfront edges.

Another workaround to what @ellharman mentioned is to set COREPACK_NPM_REGISTRY to https://registry.npmjs.org so that the package is fetched from npm CDN instead