Summary
MCP requests carry only a JSON-RPC id (number or string) for response correlation. There's no stable correlation ID propagated into the database query layer or downstream log lines. When a single MCP request triggers nested operations — batch_query invoking 10 sub-tools, impact_analysis running multiple graph traversals — operators cannot correlate the resulting log lines back to the original request. Production debugging of slow MCP sessions requires manual timestamp + argument matching across noisy logs.
Where
Suggested approach
(1) On each MCP request, generate a per-request correlation GUID (separate from the JSON-RPC id, which is client-controlled and may collide). Stash it on an AsyncLocal<> for the duration of the request. (2) Plumb the correlation GUID into: the structured trace log lines (cross-link C547), the DB query context (as a SQLite parameter cdidx.correlation_id available to any query for explain/debug), and the MCP tool telemetry envelope (cross-link C546). (3) Echo the correlation GUID back in the MCP response under _meta.correlation_id so clients can include it in their own logs. (4) For OpenTelemetry users, also create an ActivitySource span (cross-link #1679). (5) Add regression tests asserting correlation IDs propagate from request → DB query → response. (6) Document the correlation model in DEVELOPER_GUIDE under "Request correlation". (7) Cross-link with #1679, and the just-filed C546 / C547 (MCP / CLI telemetry — both consume the correlation id).
Summary
MCP requests carry only a JSON-RPC
id(number or string) for response correlation. There's no stable correlation ID propagated into the database query layer or downstream log lines. When a single MCP request triggers nested operations —batch_queryinvoking 10 sub-tools,impact_analysisrunning multiple graph traversals — operators cannot correlate the resulting log lines back to the original request. Production debugging of slow MCP sessions requires manual timestamp + argument matching across noisy logs.Where
src/CodeIndex/Mcp/McpServer.cs:130-250(HandleMessage / HandleToolsCall — id only, no propagation)src/CodeIndex/Mcp/McpToolHandlers.cs(executes — DB calls have no correlation context)Suggested approach
(1) On each MCP request, generate a per-request correlation GUID (separate from the JSON-RPC id, which is client-controlled and may collide). Stash it on an
AsyncLocal<>for the duration of the request. (2) Plumb the correlation GUID into: the structured trace log lines (cross-link C547), the DB query context (as a SQLite parametercdidx.correlation_idavailable to any query for explain/debug), and the MCP tool telemetry envelope (cross-link C546). (3) Echo the correlation GUID back in the MCP response under_meta.correlation_idso clients can include it in their own logs. (4) For OpenTelemetry users, also create anActivitySourcespan (cross-link #1679). (5) Add regression tests asserting correlation IDs propagate from request → DB query → response. (6) Document the correlation model in DEVELOPER_GUIDE under "Request correlation". (7) Cross-link with #1679, and the just-filed C546 / C547 (MCP / CLI telemetry — both consume the correlation id).