Filed by the objectuidomain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49). Unassigned, unlabelled — grading and domain:* are triage's.
The failure
The MCP search_issues tool returns a well-formed empty result instead of an error when it cannot serve a query:
search_issues("repo:objectstack-ai/objectui is:issue is:open finding")
-> {"total_count": 0, "incomplete_results": false, "items": []}
Measured against the same repo at the same moment via repo-scoped REST list + local grep over all 270 open issues:
| term | MCP search_issues | REST list + grep |
|---|
finding | 0 | 168 |
triage | 0 | 116 |
search | — | 52 |
dedup | — | 25 |
⇒ the tool reported zero for a term present in 168 of 270 open issues, with incomplete_results: false asserting the answer is complete.
⚠️It was working an hour earlier in the same session — search_issues("… StudioDesignSurface") returned 3 hits at ~00:05Z and was used as the positive control for a real dedup check. The failure appeared later, so this is a state change, not a permanently broken tool.
⛔ Why this is worse than the 403 already on record
25 open issues already record /search/issues returning 403 ("sessions are bound to their configured repositories"). That is a safe failure: the caller sees an error, knows the channel is unavailable, and switches to REST list + grep — which several dev reports this week did explicitly, and which is what produced the control column above.
A silent empty result is the opposite. It is indistinguishable from "searched, found nothing" — which is exactly the answer a dedup check is looking for. ⇒ every dedup performed while the tool is in this state passes vacuously, and the filer has no signal that anything went wrong. The repo's own discipline (a zero is only a reading if a control term that must hit is run in the same query) is the only thing standing between this and a wave of duplicate cards — and that discipline is a convention, not a mechanism.
⭐ This is the same class the lane has been finding all week in test oracles — a check that cannot fail on the condition it exists to detect — but sitting in the tooling rather than in a test.
Suggested shape (⛔ not a ruling)
Mechanical options, roughly in order of strength:
- Make the tool fail loudly. If the underlying call is refused or throttled, surface an error rather than an empty result set. A caller that gets an error switches channels; a caller that gets
[] files a duplicate. - Make the agent-side contract require a control. The dedup step in
os-dev / PM instructions could require a positive-control term in the same query shape, with the filing blocked unless the control fires — turning the existing convention into a checkable step. (Several dev reports already do this voluntarily and it is what caught this.) - Prefer REST list + local grep as the documented dedup channel for this container, since it is demonstrably reachable and its completeness is provable — one dev report tonight listed 290 rows and matched it against
open_issues_count to show the sweep was complete.
Reproduction
# via MCP
search_issues("repo:objectstack-ai/objectui is:issue is:open finding") -> total_count 0
# via repo-scoped REST, same instant
GET /repos/objectstack-ai/objectui/issues?state=open&per_page=100&page=1..3
-> 270 open issues, 168 of which contain "finding" in title or body
Dedup for this card used the REST channel with controls firing (search 52, dedup 25); silently returns empty returned 0 against those live controls, so the zero is a reading. Nearest neighbours checked and distinct: the 25 cards recording the 403, which is the loud failure, not this one.
Generated by Claude Code
Filed by the
objectuidomain:uiexecution seat (PM sessionsession_01CRJge11jso9TpXRWFt1Z49). Unassigned, unlabelled — grading anddomain:*are triage's.The failure
The MCP
search_issuestool returns a well-formed empty result instead of an error when it cannot serve a query:Measured against the same repo at the same moment via repo-scoped REST list + local grep over all 270 open issues:
search_issuesfindingtriagesearchdedup⇒ the tool reported zero for a term present in 168 of 270 open issues, with
incomplete_results: falseasserting the answer is complete.search_issues("… StudioDesignSurface")returned 3 hits at ~00:05Z and was used as the positive control for a real dedup check. The failure appeared later, so this is a state change, not a permanently broken tool.⛔ Why this is worse than the 403 already on record
25 open issues already record
/search/issuesreturning 403 ("sessions are bound to their configured repositories"). That is a safe failure: the caller sees an error, knows the channel is unavailable, and switches to REST list + grep — which several dev reports this week did explicitly, and which is what produced the control column above.A silent empty result is the opposite. It is indistinguishable from "searched, found nothing" — which is exactly the answer a dedup check is looking for. ⇒ every dedup performed while the tool is in this state passes vacuously, and the filer has no signal that anything went wrong. The repo's own discipline (a zero is only a reading if a control term that must hit is run in the same query) is the only thing standing between this and a wave of duplicate cards — and that discipline is a convention, not a mechanism.
⭐ This is the same class the lane has been finding all week in test oracles — a check that cannot fail on the condition it exists to detect — but sitting in the tooling rather than in a test.
Suggested shape (⛔ not a ruling)
Mechanical options, roughly in order of strength:
[]files a duplicate.os-dev/ PM instructions could require a positive-control term in the same query shape, with the filing blocked unless the control fires — turning the existing convention into a checkable step. (Several dev reports already do this voluntarily and it is what caught this.)open_issues_countto show the sweep was complete.Reproduction
Dedup for this card used the REST channel with controls firing (
search52,dedup25);silently returns emptyreturned 0 against those live controls, so the zero is a reading. Nearest neighbours checked and distinct: the 25 cards recording the 403, which is the loud failure, not this one.Generated by Claude Code