The firewall/MCP raw-log retention gap (access.log, gateway.jsonl, rpc-messages.jsonl missing from downloaded run artifacts) has been filed and closed as fixed at least 6 times since February 2026 (#10489, #43654, #43658, #47299, #48674, #51111) — yet today's Observability Coverage Report (discussion #51654, 2026-08-10) shows 0.0% coverage: 0 of 15 sampled firewall-enabled runs have access.log, 0 of 2 MCP-session runs have gateway.jsonl/rpc-messages.jsonl. Prior attempts (per their titles) treated this as a report-side "normalize artifact path discovery" / "remove invalid parse param" problem and each time appeared to resolve it, only for it to reappear.
A concrete new lead worth trying
This cycle separately root-caused a different long-frozen persistence bug (DeepReport's own repo-memory, see companion issue) to a file-glob/path depth mismatch: the upload/filter step used a slashless glob pattern that only matches paths exactly one directory level deep, so anything nested one level deeper than expected was silently dropped with only an info-level log line — no error, no visible failure, just quietly-missing files that looked like a clean no-op.
Given the firewall/MCP log gap has resisted 6 independent "fix" attempts over 6 months with the same symptom every time, it's worth specifically checking whether the artifact upload step (not just the report's reading side, which is what most prior fixes targeted) has an analogous glob/path-depth or pattern mismatch — e.g. logs written to a nested run-<id>/logs/access.log-style path against an upload include-pattern that only captures a shallower level, or vice versa. This hasn't been the explicit hypothesis tested in any of the 6 prior closed issues (they focused on the report's parsing/discovery logic, not the upload include-pattern itself).
Fix
- Trace the actual GitHub Actions artifact-upload step configuration for a firewall/MCP-enabled workflow and compare its include-pattern/glob against the real on-disk path where
access.log/gateway.jsonl are written during the run.
- If a depth/pattern mismatch is found, fix the upload-side glob (not just report-side path discovery) and verify by checking that the next Observability Coverage Report shows >0% raw-log coverage — don't close this until that verification happens (see companion process issue on requiring verified evidence before closing this class of bug).
Data source
Observability Coverage Report, discussion #51654, 2026-08-10; historical issue search via gh api search/issues (#10489, #43654, #43658, #47299, #48674, #51111).
Suggested Agent: New Agent (infra/observability-focused) — needs artifact-upload step access, not just report logic
Estimated Effort: Medium (1-4 hours) to trace, likely quick once the actual mismatch is located
Generated by 🔬 Deep Report · agent · 237.7 AIC · ⌖ 55.3 AIC · ⊞ 11.3K · ◷
The firewall/MCP raw-log retention gap (
access.log,gateway.jsonl,rpc-messages.jsonlmissing from downloaded run artifacts) has been filed and closed as fixed at least 6 times since February 2026 (#10489, #43654, #43658, #47299, #48674, #51111) — yet today's Observability Coverage Report (discussion #51654, 2026-08-10) shows 0.0% coverage: 0 of 15 sampled firewall-enabled runs haveaccess.log, 0 of 2 MCP-session runs havegateway.jsonl/rpc-messages.jsonl. Prior attempts (per their titles) treated this as a report-side "normalize artifact path discovery" / "remove invalid parse param" problem and each time appeared to resolve it, only for it to reappear.A concrete new lead worth trying
This cycle separately root-caused a different long-frozen persistence bug (DeepReport's own repo-memory, see companion issue) to a file-glob/path depth mismatch: the upload/filter step used a slashless glob pattern that only matches paths exactly one directory level deep, so anything nested one level deeper than expected was silently dropped with only an info-level log line — no error, no visible failure, just quietly-missing files that looked like a clean no-op.
Given the firewall/MCP log gap has resisted 6 independent "fix" attempts over 6 months with the same symptom every time, it's worth specifically checking whether the artifact upload step (not just the report's reading side, which is what most prior fixes targeted) has an analogous glob/path-depth or pattern mismatch — e.g. logs written to a nested
run-<id>/logs/access.log-style path against an upload include-pattern that only captures a shallower level, or vice versa. This hasn't been the explicit hypothesis tested in any of the 6 prior closed issues (they focused on the report's parsing/discovery logic, not the upload include-pattern itself).Fix
access.log/gateway.jsonlare written during the run.Data source
Observability Coverage Report, discussion #51654, 2026-08-10; historical issue search via
gh api search/issues(#10489, #43654, #43658, #47299, #48674, #51111).Suggested Agent: New Agent (infra/observability-focused) — needs artifact-upload step access, not just report logic
Estimated Effort: Medium (1-4 hours) to trace, likely quick once the actual mismatch is located