label: search returns pull requests that no longer have the label

[VPS-thodax]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Lists

Body

label: search returns pull requests that no longer have the label

Repository

https://github.com/vivid-planet/comet

Query

is:pr label:needs-v8-backport is:closed

Direct link:

https://github.com/vivid-planet/comet/pulls?q=is%3Apr+label%3Aneeds-v8-backport+is%3Aclosed

Steps to reproduce

1. Open the search query above.
2. Observe that PR #5989 is included in the results.
3. Open admin: Fix separation of multiple selected values in FinalFormSelect vivid-planet/comet#5989.
4. Verify that the PR currently has no labels.

Expected behavior

The label:needs-v8-backport search qualifier should only return pull requests that currently have the needs-v8-backport label.

Actual behavior

The search returns pull requests that no longer have the needs-v8-backport label, suggesting that the search index is stale or out of sync with the current label state.

Example affected PR

• admin: Fix separation of multiple selected values in FinalFormSelect vivid-planet/comet#5989

Additional information

This appears to affect closed pull requests. The PR no longer has any labels, yet it still matches the label:needs-v8-backport search qualifier.

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

[nirav-gajera]

Looking at the PR timeline, this strengthens the case that this is a search indexing bug.

The history clearly shows:

• The needs-v8-backport label was added after the PR was approved.
• A backport PR (#6008) was created and merged.
• The needs-v8-backport label was then removed from the original PR.
• The PR currently has no labels.

Since the timeline explicitly records the label removal, the current state of the PR is correct. However, the search query:

is:pr label:needs-v8-backport is:closed

still returns the PR, even though it no longer satisfies the query.

That suggests GitHub's search index is retaining a historical association with the label instead of reflecting the current label state. In other words, the repository data and the search index appear to be out of sync.

Given the reproducible example and the timeline evidence, I'd consider this a legitimate bug in GitHub's search indexing rather than expected behavior.

[LuShadowX]

Confirmed, and it isn't a UI thing — the same query through the search API returns the same stale results, so a browser cache or the logged-out rendering path isn't involved:

gh api graphql -f query='query{search( query:"repo:vivid-planet/comet is:pr label:needs-v8-backport is:closed", type:ISSUE, first:30){issueCount nodes{... on PullRequest{number labels(first:10){nodes{name}}}}}}'

count=6
#6056 labels=[]
#6011 labels=[]
#6009 labels=[]
#5998 labels=[]
#5989 labels=[]
#5918 labels=[needs-v8-backport] <- the only correct hit

I then walked the timeline of every closed PR in the repo that ever carried needs-v8-backport. Eleven had it added and later removed. Six of those dropped out of the index correctly, five never did:

PR	label removed	still in search results
#6056	2026-07-27	yes
#6011	2026-07-17	yes
#6009	2026-07-20	yes
#5998	2026-07-15	yes
#5989	2026-07-16	yes
#6027	2026-07-20	no
#6018	2026-07-20	no
#6012	2026-07-20	no
#6010	2026-07-20	no
#5953	2026-07-02	no
#5937	2026-07-01	no

That rules out the usual explanations:

• Not by design. Six of eleven removals did drop out, so label: isn't deliberately matching historical labels.
• Not simple lag. #5989 has been stale for twelve days, while [Projects Beta]: Date filters #5953 lost its label on 2 July and indexed fine.
• Not a date cutoff.Assets are now one-click further #6009 and #6027 both lost the label on 20 July — one is stale, the other is correct.

So it looks like a subset of records just never got reindexed after the unlabeled event, and from outside the repo there's nothing visible that separates the stuck five from the healthy six. Their updated_at timestamps have moved since the removal, so it isn't that the records are untouched.

Might be worth editing the five PR numbers into your original post — it gives whoever picks this up a clean set to look at rather than a single example.

One thing you could try as a stopgap, though I can't test it without write access to that repo: re-apply the label to one of the five and remove it again. If a fresh unlabeled event knocks it out of the index, that at least gives your team a manual unblock while the real fix is pending.

[soderluk]

I also am running into the same issue. Removing the label from the UI removes it from the PR, but only visually. The PR is still showing in the PR list if you filter by the label.

I tried to remove the label with GitHub CLI as well: gh pr edit <PR> --remove-label "label" and then list it gh pr list --repo owner/repo --label "label" which still returns the PR as having the label.