Summary
batch_query catches each per-query exception and adds {tool, error} to the results array, then always returns a successful (200-shaped) MCP response. There is no top-level summary field telling the client "N of M queries failed." A consumer iterating the response array must scan every element to discover any failed.
This is distinct from #1472 (which asks for a failure_scope field categorizing whether errors were cascading or isolated). C214 is about the simpler precondition: the aggregate response should signal that any failure happened at all, with counts. #1472's classification is a follow-on once the aggregate signal exists.
Where
src/CodeIndex/Mcp/McpToolHandlers.cs:1207-1218 (batch_query result aggregation)
Suggested approach
Add top-level total_count, success_count, failure_count, and partial_failure: bool fields to the batch_query response envelope. This pairs naturally with #1472 (failure_scope) and #1537 (per-query elapsed) without overlapping either.
Summary
batch_querycatches each per-query exception and adds{tool, error}to the results array, then always returns a successful (200-shaped) MCP response. There is no top-level summary field telling the client "N of M queries failed." A consumer iterating the response array must scan every element to discover any failed.This is distinct from #1472 (which asks for a
failure_scopefield categorizing whether errors were cascading or isolated). C214 is about the simpler precondition: the aggregate response should signal that any failure happened at all, with counts. #1472's classification is a follow-on once the aggregate signal exists.Where
src/CodeIndex/Mcp/McpToolHandlers.cs:1207-1218(batch_query result aggregation)Suggested approach
Add top-level
total_count,success_count,failure_count, andpartial_failure: boolfields to the batch_query response envelope. This pairs naturally with #1472 (failure_scope) and #1537 (per-query elapsed) without overlapping either.