Cannot see all pull requests

[parlato-vooma]

🏷️ Discussion Type

Bug

Body

Multiple members (maybe all) of our team cannot see their own pull requests; nor can we see all of the PRs in our repo.

While the badge on our repo says we have 130+ PRs, when clicking that link we see only 32 (19 open, 13 closed).

Simiarly, when we filter by author to our own PRs, we do not see all of our PRs. This is exacerbated in a world where each developer is managing multiple agents pushing code on their behalf.

• Multiple team members (all that have checked) report this behavior
• We have tried clearing cache/cookies/log-out-log-in

I see nothing on the status page about this incident.

[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. ⭐

[JayLeininger]

I have the issue as well. It may be related to #193388.

[Sakshamxx]

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.

[obryckim]

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.

UI shows 2

API shows all 97

[crosenfrisk]

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

[DanielRuf]

@crosenfrisk via CLI and gh pr list --limit 1000 or https://api.github.com/repos/{owner}/{repo}/pulls?state=ope.

[crosenfrisk]

Thank you!

[parlato-vooma]

This seems to have been resolved for us

[nunnatsa]

Got the same issue. Still happening.

https://github.com/kubevirt/hyperconverged-cluster-operator/pulls

Can see only one closed pr. Should be 1000s

[sherlock-wings]

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

[nunnatsa]

I eventually opened a ticket and they fixed it manually for my specific repo. They said they are working on a general solution.

[KungFuFurby]

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.

[LongYC]

Seems to be the same issues:

• https://github.com/orgs/community/discussions/192108 (PR's exist but now showing up in the UI #192108)
• https://github.com/orgs/community/discussions/193388 (Incident: closed pull requests are not showed in list page #193388)

[swifthand]

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:open or is:closed filter) 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.

[Flamefire]

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

[alalazo]

We see the same. Any change in the missing PRs reached via a link make them reappear in the list of PRs. The discrepancy between the PRs we have and the one that are shown is quite big though:

[leonardehrenfried]

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.

[Flamefire]

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.

[svetasmirnova]

Same happens for me. Repo is https://github.com/percona/percona-toolkit/pulls. Actual number of open PRs is 22, web interface shows only 10.

[ArtemBatkov]

Same. I have 2 PR opened. One is frozen, the second is active. The frozen one has gone away.

[npo-rowin-ruizendaal]

Same problem, can't see my renovate PR also not getting mail from GitHub saying there's a pr to be reviewed

[nhanguyen-netpower]

It's still happen. The repo says 21 PRs but the list only show 20 PRs

[nhanguyen-netpower]

The PR re-appeared after ~40 mins. It might have been delayed due to a large PR volume.

[Carreau]

At least can we get an acknowledgement this is still and issue and not have a "Resolved incident"?

[oleibman]

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)

[peppySrJ]

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)

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

[matthchr]

I'm still seeing this today on our repo:
https://github.com/Azure/karpenter-provider-azure/pulls?q=is%3Apr+is%3Aclosed+author%3AMaximilianoUribe
Doesnt show:
Azure/karpenter-provider-azure#1434

even though it should.

[peppySrJ]

My pull requests are still missing and GitHub support auto closed my support tickets in seconds

[meeseeksmachine]

https://news.ycombinator.com/item?id=48219231

[krassowski]

172 != 180

The problem also appears on GitHub's own repos, 2 != 5 (although if you flip it upside down...):

[DanielRuf]

That doesn't look good at all. This is definitely not fixed.

[ghutchis]

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.

[harzer1989]

I can confirm the issue. I'm also only seeing a fraction of the existing pull requests.

[smuuf]

Same here. A PR in private repo was ok an hour ago. Now its URL gives 404.

[robinvangestel21]

same here

[jrQodex]

Same with us.

[Maxime-Quesnel]

same here

[lachesisFSS]

same here

[jaimergp]

Same in conda/governance, 6 != 5:

The missing one is conda/governance#395

[DanielRuf]

I've just added (and then deleted) a comment to the PR to force the cache to refresh and it seems to have solved it on my side:

[DanielRuf]

See also https://github.com/orgs/community/discussions/193463#discussioncomment-16856972

[bougue-pe]

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>)
![image.png](<attachment>)

* 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"
  \\```
![image.png](<attachment>)

- 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)

[EliusHHimel]

I had the same problem for about a month. I contacted support, and they reindexed my PRs manually.

[ivanperez-keera]

How or where did you contact Github support?

[Mingun]

Link Contact in the footer of this page, then link in the top-right corner of that page. Create new request and select Repositories.

[ivanperez-keera]

For those of you still running into this, the following worked for me. Please be careful with how you use it. If this misfires, it could remove valuable comments from your PRs. I'm not responsible if that happens, use this (or not) at your own risk:

for i in $(gh pr list --json number | jq '.[].number'); do gh pr comment $i -b "." && gh pr comment $i --delete-last --yes; done

After running that on my side, I went to the PR list and it showed all PRs open in my repo.

You may want to remove the --yes to get a question to confirm if you want to delete the specific comment. That'd probably be safer. You may also want to open the URL printed by gh after posting each comment to check that it is indeed posted to the PR before using gh pr comment --delete-last.