Description
deep-report.md's "Fetch discussions" and "Fetch weekly issues" steps cache their GraphQL/REST results keyed only by calendar day (discussions-${TODAY}.json, weekly-issues-${TODAY}.json in /tmp/gh-aw/cache-memory, restored via a GitHub Actions cache with restore-key prefix memory-none-nopolicy-discussions-data-). But deep-report itself runs every 6 hours (cron: "9 */6 * * *"). Net effect: only the first run of each UTC day fetches live data — the next 3 runs that same day (~06:xx, ~12:xx, ~18:xx UTC) silently reuse the first run's snapshot, no matter how much real activity happened in between.
I confirmed this directly this cycle: the pre-fetched discussions.json/issues.json files handed to this run were frozen at 2026-08-16T23:55Z / 2026-08-17T00:06Z respectively (the first run of 08-17), while live GitHub already had discussions up to 2026-08-17T18:25Z and issues up to #53451 (18:21Z) — a full 18-hour, 60+ discussion / 100+ issue gap. Re-fetching directly via gh api graphql / gh api search/issues surfaced dozens of reports (Safe Output Health Monitor, CI regression on main, schema consistency findings, etc.) that three consecutive prior deep-report cycles (2026-08-17T00:26Z, 06:26Z, 12:22Z) missed entirely, each concluding "zero new discussions/issues this cycle" — a false negative caused by the cache, not an actually quiet repository.
Expected Impact
Restores deep-report's core value proposition (catching new cross-cutting patterns every 6h) for 3 of every 4 runs per day. Also prevents the same false-quiet trap for the underlying "Reduce recurring... discussions-data-fetch"/"weekly-issues-data-fetch" shared steps if any other workflow reuses them.
Suggested Agent
New Agent (or a workflow-authoring agent familiar with .github/workflows/shared/discussions-data-fetch.md / shared/weekly-issues-data-fetch.md)
Proposed Fix
Key the cache by run bucket matching the actual cron cadence (e.g. discussions-${TODAY}-${HOUR_BUCKET}.json derived from date '+%Y-%m-%d-%H' rounded to the 6h grid), or simply drop the cross-run cache entirely for a workflow that already runs every 6h — the caching optimization only makes sense for workflows that run more often than they need fresh data.
Relevant Code
.github/workflows/shared/discussions-data-fetch.md and .github/workflows/shared/weekly-issues-data-fetch.md (source)- Compiled into
.github/workflows/deep-report.lock.yml around lines 609-803 ("Fetch discussions" / "Fetch weekly issues" steps)
Estimated Effort
Quick (< 1 hour)
Data Source
DeepReport Intelligence analysis, 2026-08-17 18:23Z cycle — root-caused by comparing pre-fetched snapshot timestamps against live gh api graphql/gh api search/issues queries after 3 consecutive cycles reported suspiciously "zero new activity."
Generated by 🔬 Deep Report · agent · 227.2 AIC · ⌖ 10.6 AIC · ⊞ 11.8K · ◷
Description
deep-report.md's "Fetch discussions" and "Fetch weekly issues" steps cache their GraphQL/REST results keyed only by calendar day (discussions-${TODAY}.json,weekly-issues-${TODAY}.jsonin/tmp/gh-aw/cache-memory, restored via a GitHub Actions cache with restore-key prefixmemory-none-nopolicy-discussions-data-). Butdeep-reportitself runs every 6 hours (cron: "9 */6 * * *"). Net effect: only the first run of each UTC day fetches live data — the next 3 runs that same day (~06:xx, ~12:xx, ~18:xx UTC) silently reuse the first run's snapshot, no matter how much real activity happened in between.I confirmed this directly this cycle: the pre-fetched
discussions.json/issues.jsonfiles handed to this run were frozen at 2026-08-16T23:55Z / 2026-08-17T00:06Z respectively (the first run of 08-17), while live GitHub already had discussions up to 2026-08-17T18:25Z and issues up to #53451 (18:21Z) — a full 18-hour, 60+ discussion / 100+ issue gap. Re-fetching directly viagh api graphql/gh api search/issuessurfaced dozens of reports (Safe Output Health Monitor, CI regression on main, schema consistency findings, etc.) that three consecutive prior deep-report cycles (2026-08-17T00:26Z, 06:26Z, 12:22Z) missed entirely, each concluding "zero new discussions/issues this cycle" — a false negative caused by the cache, not an actually quiet repository.Expected Impact
Restores deep-report's core value proposition (catching new cross-cutting patterns every 6h) for 3 of every 4 runs per day. Also prevents the same false-quiet trap for the underlying "Reduce recurring... discussions-data-fetch"/"weekly-issues-data-fetch" shared steps if any other workflow reuses them.
Suggested Agent
New Agent (or a workflow-authoring agent familiar with
.github/workflows/shared/discussions-data-fetch.md/shared/weekly-issues-data-fetch.md)Proposed Fix
Key the cache by run bucket matching the actual cron cadence (e.g.
discussions-${TODAY}-${HOUR_BUCKET}.jsonderived fromdate '+%Y-%m-%d-%H'rounded to the 6h grid), or simply drop the cross-run cache entirely for a workflow that already runs every 6h — the caching optimization only makes sense for workflows that run more often than they need fresh data.Relevant Code
.github/workflows/shared/discussions-data-fetch.mdand.github/workflows/shared/weekly-issues-data-fetch.md(source).github/workflows/deep-report.lock.ymlaround lines 609-803 ("Fetch discussions" / "Fetch weekly issues" steps)Estimated Effort
Quick (< 1 hour)
Data Source
DeepReport Intelligence analysis, 2026-08-17 18:23Z cycle — root-caused by comparing pre-fetched snapshot timestamps against live
gh api graphql/gh api search/issuesqueries after 3 consecutive cycles reported suspiciously "zero new activity."