agenticworkflows logs returns silently stale (~11-day-old) data when called without explicit date-range parameters
Description: This cycle's fleet-health spot-check called agenticworkflows logs --count 30 (no start_date/end_date) and got back 30 runs all dated 2026-08-07 — 11 days stale — even though the local cache file itself was freshly written at call time (Modify: 2026-08-18 12:25:03, matching the current run). Re-running with an explicit {"count": 15, "start_date": "-1d"} immediately returned genuinely current runs (before_run_id matching today's most recent workflow runs). The bug is specifically in the default (no date params) code path of the logs tool — it silently serves an old result set instead of the most recent runs, with no warning that the data is stale.
This is the same failure shape as the previously-fixed day-keyed discussions/issues cache bug (PR #53486): a caller that doesn't supply an exact-match parameter gets a stale answer with no indication anything is wrong. Any deep-report or audit workflow that calls logs without an explicit date range (a very natural way to ask "show me the latest runs") will silently analyze 11-day-old data and report false conclusions about current fleet health.
Repro:
agenticworkflows logs --count 30 # returns 2026-08-07 runs (stale)
agenticworkflows logs --count 15 --start_date -1d # returns current runs (correct)
Expected Impact: Prevents every downstream consumer of the default logs call (deep-report, audit workflows, ad-hoc fleet checks) from silently drawing conclusions from stale data. High value — this is a foundational tool used across many reporting workflows.
Suggested Agent: New Agent / whoever owns the agenticworkflows/logs MCP tool implementation (likely pkg/cli/logs_*.go or the MCP gateway wrapper).
Estimated Effort: Medium (1-4 hours) — root-cause the default-path caching/pagination logic, likely a missing "most recent" ordering or an unbounded/mis-keyed internal cache.
Data Source: DeepReport Intelligence analysis, 2026-08-18 12:2x cycle, live tool reproduction.
Generated by 🔬 Deep Report · agent · 206 AIC · ⌖ 16.5 AIC · ⊞ 11.9K · ◷
agenticworkflows logsreturns silently stale (~11-day-old) data when called without explicit date-range parametersDescription: This cycle's fleet-health spot-check called
agenticworkflows logs --count 30(nostart_date/end_date) and got back 30 runs all dated 2026-08-07 — 11 days stale — even though the local cache file itself was freshly written at call time (Modify: 2026-08-18 12:25:03, matching the current run). Re-running with an explicit{"count": 15, "start_date": "-1d"}immediately returned genuinely current runs (before_run_idmatching today's most recent workflow runs). The bug is specifically in the default (no date params) code path of thelogstool — it silently serves an old result set instead of the most recent runs, with no warning that the data is stale.This is the same failure shape as the previously-fixed day-keyed discussions/issues cache bug (PR #53486): a caller that doesn't supply an exact-match parameter gets a stale answer with no indication anything is wrong. Any deep-report or audit workflow that calls
logswithout an explicit date range (a very natural way to ask "show me the latest runs") will silently analyze 11-day-old data and report false conclusions about current fleet health.Repro:
Expected Impact: Prevents every downstream consumer of the default
logscall (deep-report, audit workflows, ad-hoc fleet checks) from silently drawing conclusions from stale data. High value — this is a foundational tool used across many reporting workflows.Suggested Agent: New Agent / whoever owns the
agenticworkflows/logsMCP tool implementation (likelypkg/cli/logs_*.goor the MCP gateway wrapper).Estimated Effort: Medium (1-4 hours) — root-cause the default-path caching/pagination logic, likely a missing "most recent" ordering or an unbounded/mis-keyed internal cache.
Data Source: DeepReport Intelligence analysis, 2026-08-18 12:2x cycle, live tool reproduction.