Cannot see all pull requests · community · Discussion #193463

12 min read Original article ↗

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

You must be logged in to vote

0 replies

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

You must be logged in to vote

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.

You must be logged in to vote

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.

UI shows 2
image

API shows all 97
{E92D4BA8-77A5-4CC9-8496-CBDFC734E438}

You must be logged in to vote

3 replies

@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

This seems to have been resolved for us

You must be logged in to vote

0 replies

You must be logged in to vote

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

You must be logged in to vote

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.

You must be logged in to vote

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.

You must be logged in to vote

0 replies

You must be logged in to vote

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: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.
You must be logged in to vote

2 replies

@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:

2026-04-28_15-08

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.

You must be logged in to vote

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.``

You must be logged in to vote

1 reply

@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.

You must be logged in to vote

0 replies

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

You must be logged in to vote

0 replies

I just noticed this happening today with a PR I created. Wasn't happening for me yesterday.

You must be logged in to vote

0 replies

This issue still exists. Please GitHub fix it asap.

You must be logged in to vote

0 replies

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

You must be logged in to vote

0 replies

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

image
You must be logged in to vote

1 reply

@nhanguyen-netpower

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

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

You must be logged in to vote

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)

You must be logged in to vote

1 reply

@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

You must be logged in to vote

0 replies

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

image
You must be logged in to vote

0 replies

You must be logged in to vote

0 replies

172 != 180

image

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

image
You must be logged in to vote

0 replies

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

You must be logged in to vote

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.

You must be logged in to vote

0 replies

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

You must be logged in to vote

8 replies

@smuuf

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

@robinvangestel21

@jrQodex

@Maxime-Quesnel

@lachesisFSS

You must be logged in to vote

2 replies

@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:

image

@DanielRuf

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)
You must be logged in to vote

0 replies