-
Notifications
You must be signed in to change notification settings - Fork 60
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
[BUG]: Redirect option is not passed through... #635
Comments
👋 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 |
That issue that you linked is outdated. We stopped utilizing We removed the ability to pass through custom options in #599 and it was intentional that the Currently, you would need to do something like so: import { request } from "@octokit/request";
const customFetch = (url, options) => {
return fetch(url, { ...options, redirect: "manual" });
};
const { data } = await request("GET /users/{username}", {
username: "octocat",
headers: {
"X-GitHub-Api-Version": "2022-11-28",
},
options: {
request: {
fetch: customFetch,
},
},
}); |
Cheers. After reading through the details of #599 I do see where it was removed, not 100% sure why but thank you for the workaround above. I don't know if it makes sense to log a warning for some of the more common valid prior options that are now ignored. note for anyone trying to use this solution make sure to reverse the object extension from above: |
Reopening for awareness, and further discussions |
🎉 This issue has been resolved in version 9.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What happened?
Seems to be:
#611
which in theory was fixed by #612 but #612 seems to be missing any code that actually passes the redirect through, only removes it as an option on the primary object.
What is interesting is this used to work (not sure if after #612 ) octokit/octokit.js#1999 but I didn't bisect to figure out what changes stopped it from doing so.
While I could be missing something it looks like we manually build the fetch object, so I don't see how this option would be properly set other than with specifying it (see PR for this).
This specifically breaks the situation where you want to get the download URL for an artifact but not actually download it.
Versions
Octokit/request 8.1.1
Relevant log output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: