502 Server Error On Repository Search w/ OAuth Token

[cx-nitzan-massader]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

This issue has been appearing on my app for a few weeks now. When I run a repository search with the following query through my application, using a token generated via OAuth, I get a 10 second wait and then 502 Server Error.

https://api.github.com/search/repositories?q=org%3A{orgname}%20global%20archived%3Afalse%20fork%3Atrue&page=1&per_page=30&sort=updated&order=desc

The above is only an example, multiple other organizations and search params act the same. The errors are mostly consistent, with the 502 appearing 95% of the time, but sometimes results do come through.

When instead I manually change the token to use a Classic PAT I created myself, suddenly the search call works as intended. This happens both through my own application and through Postman, so I'm 99% sure it's not an applicative issue on my side.

The scopes for the OAuth app as configured are: repo,admin:repo_hook,admin:org_hook,read:org,read:user

The following is a link to the API documentation: https://docs.github.com/en/rest/search/search?apiVersion=2026-03-10#search-repositories.

Thanks in advance to anyone who thinks they can help! :)

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[hoangperry]

The 10-second wait followed by a 502 is the search backend timing out rather than a permissions rejection — and the token type changes how expensive the query is, which is why the PAT "fixes" it. With an OAuth app token, results have to be filtered through the org's third-party app access policy on top of normal visibility rules; with your own classic PAT the visibility evaluation is cheaper, and the query squeaks in under the time budget. Same query, different evaluation cost, and yours is sitting right at the edge (hence the occasional success).

Two practical ways out:

1. Make the query cheaper. sort=updated is significantly more expensive than best-match; dropping it, or narrowing with in:name instead of full-text matching on "global", often gets a borderline query back under the timeout.
2. Better: skip the search API entirely for this shape of query. Everything except the "global" text match is a listing filter, so GET /orgs/{org}/repos?sort=updated&per_page=100 plus client-side filtering (name contains "global", archived == false) is more reliable, not subject to the tiny search rate limit, and never 502s this way. For org repo inventories this is the standard approach; the search API is best kept for genuinely full-text needs.

If you specifically need to demonstrate the OAuth-vs-PAT discrepancy to GitHub, a support ticket with a request ID from a 502 response (X-GitHub-Request-Id header) is the actionable artifact — but for your app, the listing endpoint will just make the problem disappear.

[cx-nitzan-massader]

Thank you for your answer. It does seem to make sense that it's the verification of the OAuth token that is taking the time.

Regarding point 1, I tried doing as you suggested and removed the sorts and the fork & archived filters from the query, leaving only the org name and the repo name in the search, but it still doesn't work.

Regarding point 2, it's a pretty bad code smell in my opinion to have searches from our side not actually search the full list. Especially when users could have far, far more repos than just the 100 we can get from the list endpoint at any one time, making the internal filter unreliable. Currently I only use the search endpoint when a user on my side tries to filter by name, which helps, but it still usually does not work. It did work for the longest time, I do wonder if there was some change on GitHub's side that started causing this.