💬 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. ⭐
0 replies
I have the issue as well. It may be related to #193388.
0 replies
This usually happens when the platform’s PR counter and PR list are powered by different systems. The badge count can stay correct, while the searchable/list view falls behind because of an indexing or sync issue.
0 replies
We're seeing the same thing on multiple repositories.
The closed PR list is either zero or just 1-2 items (even when we have 100+ closed PRs).
Getting the list of closed PRs from the API is returning the true list.
Also, navigating to those PRs directly (e.g. https://github.com/org/repo/pull/123) works fine too.
3 replies
Hi! How did you find your true list via the API? I'm used to using the GH interface but would love to try to track down my "lost" PRs. Thank you @obryckim
@crosenfrisk via CLI and gh pr list --limit 1000 or https://api.github.com/repos/{owner}/{repo}/pulls?state=ope.
This seems to have been resolved for us
0 replies
0 replies
I am seeing the same issue-- should have over 400 PRs but I have 0. This persist after cache/cookies clear from "All Time" and machine reboot
0 replies
I eventually opened a ticket and they fixed it manually for my specific repo. They said they are working on a general solution.
0 replies
Yes, I'm affected at the AddmusicKFF repo. The oldest pull requests are not shown in the results and the counter also doesn't even factor them in.
0 replies
0 replies
I am seeing this in a private repo:
- I can access a particular open PR by direct URL, and it is still open.
- This PR does not appear in the list of all PRs with the filters
is:pr is:open. - The PR does not appear in the list of closed PRs either (which is correct, because it is still open).
- Filtering the PR list by the author of the PR (with no
is:openoris:closedfilter) does not display the PR. - The PR also does not appear when searching for PRs via API.
UPDATE:
- Another team member on the project also could not see the PR. It was not only me experiencing the issue.
- I submitted a review on the missing PR, and after doing so it was visible in the list of all PRs. I do not know if making my comment invalidated some cache and shook it back into view, or if some other process (or the passage of time) happened to coincide with making a comment on the PR.
2 replies
This matches what I see too:
- Number of PRs in badge and "open" tab does not match
- filtering by PR title and/or state (
author,is:pr,is:open, etc) does not show this PR - Going to the expected page in the PR list is missing it. Numbers are: ..., 25730, 25729, 25698, 25697, 25696, ...
I.e. 31 PRs are missing in this region.
The same applies to the GraphQL via cmdline and gh tool: Those are not returned
I can confirm that about 2/3 of my pull requests on an open source project are not listed when I filter for me as the author.
0 replies
Based on @nunnatsa's update (GitHub fixed it manually per repo) and @swifthand's observation that submitting a review made the PR reappear, the root cause is a search index desync — the PR exists in the database but is missing from the search/list index.
What works right now:
Submit a support ticket referencing your repo directly — they can manually reindex it (confirmed working per @nunnatsa)
As a workaround, the API returns accurate results even when the UI doesn't: gh pr list --limit 1000 or direct REST/GraphQL calls will show all PRs
Why the comment/review trick works (@swifthand): writing to a PR triggers an index update event for that object, which forces a reindex of that specific PR. It's not guaranteed but explains the pattern.
This appears to be the same underlying incident as #192108 and #193388. GitHub is working on a general fix but is currently doing per-repo manual remediation on ### request.``
1 reply
Doesn't seem to work for me, at least not when using a query: gh pr list --limit 1000 seems to include the PRs but gh api graphql with a simple query like repo:[...] is:pr shows a lot but is still missing the same ones as in the UI, e.g. I see PR numbers 25730, 25729, 25698, 25697, 25696, ... I.e. 31 PRs are missing in this region.
0 replies
Same. I have 2 PR opened. One is frozen, the second is active. The frozen one has gone away.
0 replies
I just noticed this happening today with a PR I created. Wasn't happening for me yesterday.
0 replies
This issue still exists. Please GitHub fix it asap.
0 replies
Same problem, can't see my renovate PR also not getting mail from GitHub saying there's a pr to be reviewed
0 replies
1 reply
At least can we get an acknowledgement this is still and issue and not have a "Resolved incident"?
0 replies
After several days of waiting, Github Support finally got to my ticket and resolved it by manually reindexing my repository. So, if you have the patience to open a ticket (becoming very difficult in the new AI world), it can probably be resolved for other individual repositories.
As part of my ticket, I issued the following curl command:
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer yourGithubPassword" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/repos/PhpOffice/PhpSpreadsheet/pulls
You'll have to replace yourGithubPassword and PhpOffice/PhpSpreadsheet above.
From the output of that command, I was able to determine which PR's were missing. The numbers were relatively small for me (8 missing out of 16), so that wasn't too onerous; if your repository is bigger, it may be a problem.
A manual workaround which might be of use without Github Support's intervention is described at PHPOffice/PhpSpreadsheet#4873 (comment)
1 reply
After several days of waiting, Github Support finally got to my ticket and resolved it by manually reindexing my repository. So, if you have the patience to open a ticket (becoming very difficult in the new AI world), it can probably be resolved for other individual repositories.
As part of my ticket, I issued the following
curlcommand:curl -L \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer yourGithubPassword" \ -H "X-GitHub-Api-Version: 2026-03-10" \ https://api.github.com/repos/PhpOffice/PhpSpreadsheet/pullsYou'll have to replace
yourGithubPasswordandPhpOffice/PhpSpreadsheetabove. From the output of that command, I was able to determine which PR's were missing. The numbers were relatively small for me (8 missing out of 16), so that wasn't too onerous; if your repository is bigger, it may be a problem.A manual workaround which might be of use without Github Support's intervention is described at PHPOffice/PhpSpreadsheet#4873 (comment)
This worked wonderfully for me. I was able to use this curl to fetch the PR list (I added ?state=open to the endpoint to filter out only open PRs), and then I added a comment to all of them to bring them back.
One correction to the curl call above - instead of yourGithubPassword it should be your Personal Access Token
0 replies
0 replies
0 replies
0 replies
That doesn't look good at all. This is definitely not fixed.
0 replies
I was just looking for one of my pull requests - it's not at all visible on the web.
On the web: 8 open pull requests
From gh pr list I get 14 (it's also the correct number in the "Pull Requests 14" section at the top of the page.
When I opened a support request, Copilot was telling me everything was fine. No, no it's not.
0 replies
I can confirm the issue. I'm also only seeing a fraction of the existing pull requests.
8 replies
2 replies
We had the same issue, and the "re-comment" trick was not an option for us.
Thanks to https://github.com/orgs/community/discussions/193463#discussioncomment-17001348, we were able to open a support ticket and they manually re-indexed it all ✅
🤷 I don't get why this general re-indexing is still missing 1 month later: crawling for broken indexes is doable if willing to save some CPU ⚖️ (and I don't know how hard it is to automate re-indexing).
Here is the framework of the ticket if it can help:
Ticket topic route: Pull requests --> Loading issues --> Something else
Title: Incomplete pull request results in repositories
Hello, We are still experiencing the "incomplete pull request results" issue right now even after resolution of the Github incident. ## Observations * ~X00 PRs listed (vs. ~X0_000 in total) on https://github.com/<org/repo>/pulls?q=is%3Apr+sort%3Acreated-asc, and the oldest PR listed is [#<PR>](https://github.com/<PR>)  * Using github API, the oldest PR listed is [#<PR>](https://github.com/<org/repo>/pull/<PR>) Using \\```sh curl -L \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer github_pat_<something>" \ -H "X-GitHub-Api-Version: 2026-03-10" \ "https://api.github.com/repos/<org/repo>/pulls?state=all&sort=created&order=asc&per_page=5" \\```  - Other broken github features: trying to access the PR where [this commit](https://github.com/<org/repo>/commit/<commit>) was introduced is currently impossible. ## Expectations Web (and navigable) access to pull-request is an important feature to understand history of choices made on the codebase when bugfixing, refactoring or adding new features. Relying on the pure git history misses some information and is not the part of github that stands out vs. any other git repository. :pray: Is it possible to re-index the repositories of https://github.com/<org>? (github mentionned that it solves the issue) ## Resources read before opening this ticket - https://www.githubstatus.com/ (no ongoing incident listed) - https://www.githubstatus.com/incidents/x69zbgdyfzg0 - https://github.com/orgs/community/discussions/194219 (subscribed, no recent news) - https://github.com/orgs/community/discussions/193463 (subscribed)
0 replies







