Multiple -involves:foo no longer work in PR searches

[pbsds]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Code Search and Navigation

Body

I like to filter various prolific users and bots while looking for PRs to review. But with the update you cannot use -involves:<user> multiple times anymore, it filters nothing now.

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

[Sagargupta16]

Reproduced, with numbers, on NixOS/nixpkgs open PRs (2026-10-01, logged out):

Query on the repo's Pull requests page	Count
is:pr is:open	12262
-involves:r-ryantm	10024
-involves:r-ryantm -involves:Mic92	12262
-author:r-ryantm -author:Mic92 (control)	10033
-commenter:r-ryantm -commenter:Mic92 (control)	11466

So a second -involves does not narrow further, it silently drops the whole involves filter and returns the unfiltered list. Other negated qualifiers still stack. This is specific to the refreshed repository pull requests page that went generally available on 2026-09-21; the same query string still works everywhere else: the global search page (/search?type=pullrequests&q=repo:NixOS/nixpkgs is:pr is:open -involves:r-ryantm -involves:Mic92) returns 9.9k, and the search API returns 9876. The page's new AND and parenthesised forms did not rescue it in my tests either.

Two workarounds until it is fixed:

1. Expand involves into the four qualifiers it is defined as, per user. On the PR page this gives 9944 for the example above, 68 more than the exact -involves result (the API agrees on 9944, so the expansion itself is honoured):

is:pr is:open -author:r-ryantm -assignee:r-ryantm -mentions:r-ryantm -commenter:r-ryantm -author:Mic92 -assignee:Mic92 -mentions:Mic92 -commenter:Mic92

Save it as a custom filter in the sidebar once and forget about it.

2. Use the global search page with a repo: qualifier, or the CLI, both of which still honour repeated -involves:

gh search prs --repo NixOS/nixpkgs --state open -- -involves:r-ryantm -involves:Mic92

The precise failure to report (and this thread is the feedback channel the page points at): on /OWNER/REPO/pulls, two or more -involves: terms return the same count as no involves filter at all, while the same string on /search and in the API filters correctly.

[kurupdevs]

Can confirm this is a genuine regression rather than anything wrong with your query. Sagargupta16's numbers reproduce it cleanly: a single negated involves filters correctly, but adding a second one returns the same count as no filter at all, while other negated qualifiers still stack.

My reading is that involves: is documented as a logical OR of author, assignee, mentions and commenter for a single user, so stacking the qualifier twice on the refreshed PR page looks like a parser edge case where the repeated term gets silently dropped and results come back unfiltered.

As a workaround, you can state the intent directly with the documented boolean syntax on the Pull requests page instead, something like NOT (involves:r-ryantm OR involves:Mic92), which avoids repeating the qualifier.

[updalla-apshir]

Confirmed. This looks like a genuine regression on the refreshed repository Pull Requests page: a single -involves: filter works, but adding a second one causes the involves filtering to be dropped entirely.

The fact that the same query still works in global search and the API makes this look specific to the new PR page rather than a change to the search syntax itself.