Description
Today's Observability Coverage Report (discussion #53243, Observability Coverage Report - 2026-08-16) found that across 20 MCP-enabled runs / 202 sampled rpc-messages.jsonl telemetry entries, 0 of 202 exposed a top-level type field, even though the report's own rubric (and the workflow prompt's documented schema in .github/workflows/daily-observability-report.md, Phase 3.4) both expect type: "REQUEST" | "RESPONSE" as a required top-level field for that file format.
Cross-referencing this against the codebase: pkg/cli/gateway_logs_types.go defines RPCMessageEntry.Type with JSON tag json:"type", and pkg/cli/gateway_logs_rpc.go's parseRPCMessages directly unmarshals each line into that struct and branches on entry.Type == "REQUEST" / "RESPONSE" to compute tool-call counts and durations. If real production rpc-messages.jsonl files (written by the Copilot CLI engine, not by gh-aw's own code) genuinely lack a top-level type field, entry.Type silently defaults to "" for every line, no error is raised, and every derived metric in GatewayMetrics from this fallback path (tool-call counts, durations, request/response pairing) is silently wrong/zero — a much bigger problem than the observability report's own "warning" framing suggests, since it would mean our own consumer code has been quietly mis-parsing this fallback telemetry format.
This has NOT been independently verified against a raw rpc-messages.jsonl sample in this session — it's flagged based on cross-referencing the audit report's empirical finding against the parser's field expectations, and could equally be a false positive in the observability-report's own detection logic. Needs direct verification (pull one real rpc-messages.jsonl from a recent MCP-enabled run and check its actual field names) before assuming either the parser or the report is at fault.
Expected Impact
If confirmed, this would fix silently-broken MCP metrics (tool-call counts, durations) for any run relying on the rpc-messages.jsonl fallback path (used whenever gateway.jsonl is absent) — currently the majority per today's report (20/20 sampled MCP-enabled runs used the fallback, 0 had gateway.jsonl).
Suggested Agent
New Agent — needs to fetch a real recent rpc-messages.jsonl artifact and diff its actual field names against RPCMessageEntry's expectations before deciding whether the fix belongs in the parser, the Copilot CLI integration, or the observability-report's own detection script.
Estimated Effort
Quick (< 1 hour) to verify; Medium (1-4 hours) if the parser itself needs a field-name fix.
Data Source
DeepReport Intelligence analysis, 2026-08-17 cycle (discussion #53243, cross-referenced against pkg/cli/gateway_logs_types.go and pkg/cli/gateway_logs_rpc.go). Flagged as an investigation, not a confirmed fix — see verification caveat above.
Generated by 🔬 Deep Report · agent · 239.4 AIC · ⌖ 7.81 AIC · ⊞ 11.8K · ◷
Description
Today's Observability Coverage Report (discussion #53243, Observability Coverage Report - 2026-08-16) found that across 20 MCP-enabled runs / 202 sampled
rpc-messages.jsonltelemetry entries, 0 of 202 exposed a top-leveltypefield, even though the report's own rubric (and the workflow prompt's documented schema in.github/workflows/daily-observability-report.md, Phase 3.4) both expecttype: "REQUEST" | "RESPONSE"as a required top-level field for that file format.Cross-referencing this against the codebase:
pkg/cli/gateway_logs_types.godefinesRPCMessageEntry.Typewith JSON tagjson:"type", andpkg/cli/gateway_logs_rpc.go'sparseRPCMessagesdirectly unmarshals each line into that struct and branches onentry.Type == "REQUEST"/"RESPONSE"to compute tool-call counts and durations. If real productionrpc-messages.jsonlfiles (written by the Copilot CLI engine, not by gh-aw's own code) genuinely lack a top-leveltypefield,entry.Typesilently defaults to""for every line, no error is raised, and every derived metric inGatewayMetricsfrom this fallback path (tool-call counts, durations, request/response pairing) is silently wrong/zero — a much bigger problem than the observability report's own "warning" framing suggests, since it would mean our own consumer code has been quietly mis-parsing this fallback telemetry format.This has NOT been independently verified against a raw
rpc-messages.jsonlsample in this session — it's flagged based on cross-referencing the audit report's empirical finding against the parser's field expectations, and could equally be a false positive in the observability-report's own detection logic. Needs direct verification (pull one realrpc-messages.jsonlfrom a recent MCP-enabled run and check its actual field names) before assuming either the parser or the report is at fault.Expected Impact
If confirmed, this would fix silently-broken MCP metrics (tool-call counts, durations) for any run relying on the
rpc-messages.jsonlfallback path (used whenevergateway.jsonlis absent) — currently the majority per today's report (20/20 sampled MCP-enabled runs used the fallback, 0 hadgateway.jsonl).Suggested Agent
New Agent — needs to fetch a real recent
rpc-messages.jsonlartifact and diff its actual field names againstRPCMessageEntry's expectations before deciding whether the fix belongs in the parser, the Copilot CLI integration, or the observability-report's own detection script.Estimated Effort
Quick (< 1 hour) to verify; Medium (1-4 hours) if the parser itself needs a field-name fix.
Data Source
DeepReport Intelligence analysis, 2026-08-17 cycle (discussion #53243, cross-referenced against
pkg/cli/gateway_logs_types.goandpkg/cli/gateway_logs_rpc.go). Flagged as an investigation, not a confirmed fix — see verification caveat above.