[BUG]: Artifact download fails with permission issue

[tibetiroka]

What happened?

In the latest version, downloading workflow artifacts fails with a permission issue (403 forbidden). This does not occur in older versions; specifically, I tested v18.12.0, and it worked using the exact same code and token. (I checked and my token is valid and has the necessary permissions; the only change between the two scenarios is the version of octokit/rest.)

Versions

Octokit/rest v20.1.0

Relevant log output

RequestError [HttpError]: Unknown error: {}
    at [...] {
  status: 403,
  response: {
    url: '[...]',
    status: 403,
    headers: {
      'access-control-allow-origin': '*',
      'access-control-expose-headers': 'Content-Length,Content-Type,Date,Server,x-ms-request-id',
      'content-length': '321',
      'content-type': 'application/xml',
      date: 'Sun, 07 Apr 2024 13:19:07 GMT',
      server: 'Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0',
      'x-ms-request-id': '0e7ac65f-001e-0077-23ee-8849b0000000'
    },
    data: ArrayBuffer {
      [Uint8Contents]: <[...] ... 221 more bytes>,
      byteLength: 321
    }
  },
  request: {
    method: 'GET',
    url: '[...]',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': 'octokit-rest.js/20.1.0 octokit-core.js/5.2.0 Cloudflare-Workers',
      authorization: 'token [REDACTED]'
    },
    request: { hook: [Function: bound bound register], redirect: 'manual' }
  }
}

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[tibetiroka]

After some more testing, I managed to narrow the bug's introduction to between 20.0.0-beta.3 and 20.0.0-beta.4.

[wolfy1339]

We switched to using native fetch instead of node-fetch in v8 of @octokit/request and the redirect option was removed. See octokit/request.js#635

Your issue may have something to do with that.

Can you share a minimal example?

[tibetiroka]

The issue can be reproduced using this repo, it's about 60 lines of code.

After removing the redirect, I can get downloadArtifact to work from the console, but not when running via wrangler. (Some people I talk to had trouble with having itty-router present, but that doesn't seem to cause issues for me.)

I also experimented with accessing the backend directly, using the URL address of the request when it fails. Although it gives 403 when first accessed via downloadArtifact, a regular, unauthenticated request made from plain JS tends to work on my machine. (It does not work when deployed in a Cloudflare Worker, however, though afaik they use a slightly different JS engine. It still gives 403 there. This was tested on a public artifact from a public repo that everyone should have access to.)

Does this mean it's a wrangler/cloudflare issue, then?