Metrics Collector: push_repo_memory fails 6 consecutive runs — daily JSON exceeds 100KB file-size cap

[github-actions]

Problem

Metrics Collector's push_repo_memory job has failed on 6 consecutive scheduled runs (2026-08-23 through 2026-08-28), each time hard-failing on the same gate: the daily metrics snapshot file exceeds the configured 100 KB per-file cap.

Affected workflow: Metrics Collector (.github/workflows/metrics-collector.md / .lock.yml, job push_repo_memory)

Evidence (size-limit errors from job logs)

Run date	File	Size	Cap
2026-08-23	metrics/daily/2026-08-23.json	286,128 bytes	102,400 bytes
2026-08-24	metrics/daily/2026-08-24.json	598,825 bytes	102,400 bytes
2026-08-25	metrics/daily/2026-08-25.json	359,299 bytes	102,400 bytes
2026-08-28	metrics/daily/2026-08-28.json	335,451 bytes	102,400 bytes

Runs: 33143778663 (Aug 28), 33038491364 (Aug 27), 32924199594 (Aug 26), 32802543912 (Aug 25), 32684298301 (Aug 24), 32613752970 (Aug 23).

Current config (.github/workflows/metrics-collector.lock.yml):

"push_repo_memory":{"memories":[{"dir":"/tmp/gh-aw/repo-memory/default","id":"default","max_file_count":100,"max_file_size":102400,"max_patch_size":131072}]}

Impact

• All 6 runs since Aug 23 failed at the push_repo_memory step (the agent step itself succeeds; only the memory write is rejected).
• metrics/daily/*.json for these dates never landed in shared repo memory — daily-level history has gaps, degrading trend/MTBF analysis for downstream consumers (Workflow Health Manager, Agent Performance Analyzer, Campaign Manager all read from /tmp/gh-aw/repo-memory/default/metrics/).
• metrics/latest.json is still updated each run (single combined file, currently ~35 KB, under cap), so daily snapshots are the only casualty — but the 30-day trend view is now missing 4+ days.
• This is a recurring failure class (see prior fixes Prevent Agent Performance Analyzer repo-memory push failures by raising patch-size cap #48012, [aw-failures] Metrics Collector push_repo_memory hard-fails on 131KB patch vs 10KB cap #49931, [aw-failures] [aw-fix] daily-code-metrics push_repo_memory hard-red — history.jsonl (112KB) exceeds max-file-size 100KB, memory [Content truncated due to length] #43865 for the same symptom on other workflows/dates) — each prior fix simply raised the cap, and the payload has since grown past the new cap again.

Probable root cause

The daily metrics payload (ecosystem + full per-workflow workflows map, now 287 workflows) has grown well past the historical ~30-50 KB size that the 100 KB cap was originally sized for. Payload size looks likely to keep growing as the workflow count increases, so a flat cap will need repeated bumps unless growth is bounded.

Suggested fix

1. Raise max_file_size for the metrics/daily/*.json memory entry from 100 KB to a value with real headroom over current peak (~600 KB seen on Aug 24) — e.g. 768 KB–1 MB — mirroring the pattern used in Prevent Agent Performance Analyzer repo-memory push failures by raising patch-size cap #48012/[aw-failures] Metrics Collector push_repo_memory hard-fails on 131KB patch vs 10KB cap #49931.
2. Consider also raising max_patch_size (currently 128 KB) since a single day's file addition alone can exceed that once the per-file cap is raised.
3. Longer-term: prune/summarize per-workflow detail in daily snapshots (e.g. drop workflows with zero runs, or store only deltas) so the file size grows sub-linearly with the number of onboarded workflows, reducing how often the cap needs revisiting.
4. Backfill is not required — accept the 4-day gap in metrics/daily/ once the cap fix lands.

Success criteria

• push_repo_memory in Metrics Collector completes without a size-limit error on the next 3 consecutive scheduled runs.
• max_file_size/max_patch_size changes reflected in both metrics-collector.md and its compiled .lock.yml.
• No regression in existing 30-day pruning behavior for metrics/daily/.

---

Detected by: Workflow Health Manager (meta-orchestrator) — run 33149685145

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• api.github.com

[!TIP]
api.github.com is blocked because GitHub API access uses the built-in GitHub tools by default. Instead of adding api.github.com to network.allowed, use tools.github.mode: gh-proxy for direct pre-authenticated GitHub CLI access without requiring network access to api.github.com:

tools:
  github:
    mode: gh-proxy

See GitHub Tools for more information on gh-proxy mode.

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "api.github.com"

See Network Configuration for more information.

Generated by 🏥 Workflow Health Manager - Meta-Orchestrator · copilot · auto · 63.1 AIC · ⌖ 5.34 AIC · ⊞ 12.5K · ◷

• expires on Aug 28, 2026, 11:03 PM UTC-08:00

[github-actions]

🍪 Issue Monster selected this for Copilot

I've identified this issue as a good candidate for automated resolution and requested assignment to the Copilot coding agent.

If assignment succeeds, the Copilot coding agent will analyze the issue and create a pull request with the fix.

Om nom nom! 🍪

Warning

Firewall blocked 4 domains

The following domains were blocked by the firewall during workflow execution:

• ab.chatgpt.com
• api.github.com
• chatgpt.com
• github.com

[!TIP]
api.github.com is blocked because GitHub API access uses the built-in GitHub tools by default. Instead of adding api.github.com to network.allowed, use tools.github.mode: gh-proxy for direct pre-authenticated GitHub CLI access without requiring network access to api.github.com:

tools:
  github:
    mode: gh-proxy

See GitHub Tools for more information on gh-proxy mode.

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "ab.chatgpt.com"
    - "api.github.com"
    - "chatgpt.com"
    - "github.com"

See Network Configuration for more information.

🍪 Om nom nom by Issue Monster · codex · mai10 · 3.05 AIC · ⌖ 0.785 AIC · ⊞ 19.2K · ◷

[github-actions]

This issue was automatically closed because it expired on 2026-08-29T07:03:39.029Z.

Closed by Workflow