Description
The GitHub API Consumption Report (discussion #53972, run 2026-08-19) requested the logs tool with an explicit 90-day backfill window but got back only 100 runs from a single calendar date, 2026-08-07 — the exact same date implicated in the previously-filed stale-data bug #53683, whose fix (PR #53719) only added a warning to the no-date-range code path. This occurrence used an explicit start_date range, not the default path, and still truncated to one stale day — suggesting either the fix doesn't cover explicit wide-range calls, or a separate pagination bug (e.g. early truncation while iterating from the oldest matching day) still exists in the logs tool's retrieval logic. Every trend chart in that report (90-day API-calls trend, 30-day per-workflow trend, 90-day hourly heatmap) is built entirely on this single stale day, silently invalidating the multi-day rollups.
Expected Impact
Fixing the actual retrieval/pagination root cause (not just a warning banner) protects every report/audit workflow that requests a wide explicit date range for trend analysis (API Consumption Report, Daily Performance Summary, etc.) from silently analyzing incomplete/stale data.
Suggested Agent
Same maintainers who fixed #53683/PR #53719 — likely needs tracing through pkg/cli/logs_orchestrator.go's pagination path for explicit start_date/end_date ranges.
Estimated Effort
Medium (1-4 hours) — reproduce with a real 90-day start_date and trace why results stop at one day.
Data Source
DeepReport analysis 2026-08-19, discussion #53972 (GitHub API Consumption Report), related to #53683 / PR #53719.
Generated by 🔬 Deep Report · agent · 174 AIC · ⌖ 12.1 AIC · ⊞ 11.9K · ◷
Description
The GitHub API Consumption Report (discussion #53972, run 2026-08-19) requested the
logstool with an explicit 90-day backfill window but got back only 100 runs from a single calendar date, 2026-08-07 — the exact same date implicated in the previously-filed stale-data bug #53683, whose fix (PR #53719) only added a warning to the no-date-range code path. This occurrence used an explicitstart_daterange, not the default path, and still truncated to one stale day — suggesting either the fix doesn't cover explicit wide-range calls, or a separate pagination bug (e.g. early truncation while iterating from the oldest matching day) still exists in thelogstool's retrieval logic. Every trend chart in that report (90-day API-calls trend, 30-day per-workflow trend, 90-day hourly heatmap) is built entirely on this single stale day, silently invalidating the multi-day rollups.Expected Impact
Fixing the actual retrieval/pagination root cause (not just a warning banner) protects every report/audit workflow that requests a wide explicit date range for trend analysis (API Consumption Report, Daily Performance Summary, etc.) from silently analyzing incomplete/stale data.
Suggested Agent
Same maintainers who fixed #53683/PR #53719 — likely needs tracing through
pkg/cli/logs_orchestrator.go's pagination path for explicitstart_date/end_dateranges.Estimated Effort
Medium (1-4 hours) — reproduce with a real 90-day
start_dateand trace why results stop at one day.Data Source
DeepReport analysis 2026-08-19, discussion #53972 (GitHub API Consumption Report), related to #53683 / PR #53719.