fix(mcp): filter find_incidents by status in SQL, not after the limit (audit M8) - #438
Merged
Merged
Conversation
`Incident::list_open_since` orders by `opened_at desc` with a SQL `LIMIT` (100 by default); `find_incidents` then applied the open/resolved filter in Rust, on that already truncated page. So `status: "open"` returned only the open incidents *among the 100 most recently opened rows*. The lookback window commonly holds more sub-grace flap rows than the limit, and they sort by `opened_at` alongside everything else. A still-open incident that opened six days ago therefore sits below them and is omitted entirely — from the list and from both counts. An active incident becomes invisible in the tool built for triage. The filter moves into the query as an `IncidentStatusFilter`, so the limit bounds the filtered set. `open` stays "not closed" and `resolved` stays "operator-resolved"; those overlap, since an operator can resolve an incident that is still open, and that is unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SGfH1cdFKPnKpM7ytRThft
…mcp-find-incidents
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 M8 (medium) from the audit in #370.
The bug
Incident::list_open_sinceorders byopened_at descwith a SQLLIMIT(default 100).find_incidentsthen applied the open/resolved filter in Rust, on that already-truncated page — sostatus: "open"returned only the open incidents among the 100 most recently opened rows.The lookback window commonly holds more sub-grace flap rows than the limit, and those sort by
opened_atalongside everything else. A still-open incident that opened six days ago sits below them and is omitted entirely — from the list and fromcountandpublished_count. An active incident goes invisible in the tool built for triage.The fix
The filter moves into the query as an
IncidentStatusFilter(All/Open/Resolved), so the limit bounds the filtered set. Semantics are unchanged:openis "not closed",resolvedis "operator-resolved", and they overlap because an operator can resolve an incident that's still open.Tests
New
crates/database/tests/it/incident_list_status.rs:the_status_filter_is_applied_before_the_limit— one incident opened six days ago and still open, ten closed flap rows from the last hour, limit 5: the open one still comes back.the_status_filter_selects_the_right_incidents— All/Open/Resolved pick the right rows, including the resolved-but-not-closed overlap.Note for reviewers: the second test uses two groups because a partial unique index (
incidents_open_by_group) allows only one open incident per group.Third of four in the audit's "filter-after-LIMIT in the MCP layer" pattern (M7, M8, M9, L14).
Generated by Claude Code