Skip to content

MCP batch_query has no failure_scope field for cascading vs isolated errors #1472

Description

@Widthdom

Summary

batch_query returns per-entry success/failure but does not signal whether failures are isolated (each entry failed on its own merits) or cascading (something happened mid-batch and the rest were never attempted). Without that distinction, a client cannot tell "5 succeeded, 5 failed because each had bad args" from "5 succeeded, 5 failed because the DB connection died after entry 5".

Evidence

  • src/CodeIndex/Mcp/McpToolHandlers.cs:1206-1210 (ExecuteBatchQuery catch) — exceptions are recorded per entry; the response has no top-level field describing the batch's failure mode.

Impact

  • Clients implementing retry logic over a batch must guess: retry just the failed entries (correct for isolated failures, wasteful for cascading), or retry the entire batch (correct for cascading, redundant for isolated).
  • Logs of partial failures are harder to interpret because the cause is implicit.

Proposed direction

Add a top-level field, e.g. failure_scope, to the batch response with values like:

  • "none" — all entries succeeded
  • "isolated" — failures occurred but each entry was attempted and failed independently
  • "cascading" — a transient failure mid-batch prevented later entries from running (and they're returned as errored or omitted)

When cascading, also return cascade_started_at_index. Document the field in the MCP tool description.

Repro env

  • Branch: main @ 2ee912d (release v1.21.0)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions