fix(mcp): filter find_issues by server in SQL, not after the limit (audit M7) - #437
Merged
Merged
Conversation
`Issue::list` orders by `last_seen desc` with a SQL `LIMIT` (100 by default); `find_issues` then applied its `server_id` filter in Rust, on that already truncated page. `group_id` is part of the query, so only this one filter bit after the fact. With more active issues fleet-wide than the limit, a server whose issues were seen slightly earlier than the top N returns `count: 0` — an agent triaging that server is told it is clean while it is not. The quieter the server, the more likely it is to be misreported. `server_id` joins the other filters in `IssueListFilters`, so the limit bounds the filtered set. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SGfH1cdFKPnKpM7ytRThft
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes M7 (medium) from the audit in #370.
The bug
Issue::listorders bylast_seen descwith a SQLLIMIT(default 100).find_issuesthen applied itsserver_idfilter in Rust —issues.retain(…)— on that already-truncated page. Every other filter, includinggroup_id, is part of the query; only this one bit after the fact.With more active issues fleet-wide than the limit, a server whose issues were seen slightly earlier than the top N returns
count: 0. An agent triaging that server is told it's clean when it isn't — and the quieter the server, the likelier that is, which is exactly backwards.The fix
server_idjoins the other fields onIssueListFiltersand is applied in SQL, so the limit bounds the filtered set.private-server'sissues::listpassesNoneand is unaffected.Tests
New
crates/database/tests/it/issue_list_filters.rs:the_server_filter_is_applied_before_the_limit— a noisy server with 10 recent issues, a quiet one whose single issue was seen longest ago, and a limit of 5: the quiet server's issue still comes back.the_server_filter_excludes_other_servers— the filter does what it says.This is one of four sites in the audit's "filter-after-LIMIT in the MCP layer" pattern (M7, M8, M9, L14); the others are separate PRs.
Generated by Claude Code