Problem Description
The logs tool consistently times out with Error [0]: context deadline exceeded when called without a workflow_name filter, even with minimal parameters (count: 1, max_tokens: 1000, start_date: "-6h").
With a workflow_name filter, the same query completes in ~6–7 seconds.
Tool
Steps to Reproduce
-
Call logs without workflow_name:
printf '{"start_date":"-1d","count":3,"max_tokens":3000}' | agenticworkflows logs .
-
Observe timeout at ~60 seconds: Error [0]: context deadline exceeded
-
Call logs WITH workflow_name:
printf '{"start_date":"-7d","count":2,"max_tokens":2000,"workflow_name":"ab-testing-advisor"}' | agenticworkflows logs .
-
Observe it completes successfully in ~6s.
Expected Behavior
Logs should be retrievable without specifying a workflow name. The workflow_name parameter is optional per the tool schema, so unfiltered queries should work (perhaps returning a subset).
Actual Behavior
Any logs call without workflow_name hits a 60-second context deadline, regardless of count, max_tokens, or start_date window size.
Tested Variations (all timed out)
start_date |
count |
max_tokens |
workflow_name |
Result |
-1d |
3 |
3000 |
(none) |
❌ timeout 60s |
-1d |
2 |
2000 |
(none) |
❌ timeout 60s |
-6h |
1 |
1000 |
(none) |
❌ timeout 60s |
-7d |
2 |
2000 |
ab-testing-advisor |
✅ ~6s |
-7d |
2 |
1000 |
daily-cli-tools-tester |
✅ ~7s |
Environment
- Repository: github/gh-aw
- Run ID: 30242071107
- Date: 2026-07-27
Impact
- Severity: High — the most natural usage (browsing recent runs across all workflows) is completely broken
- Frequency: Always
- Workaround: Always specify
workflow_name parameter
Root Cause Hypothesis
The unfiltered query likely triggers fetching/listing all workflow runs from the GitHub API without pagination limits applied server-side, causing the 60s MCP context deadline to expire before results arrive.
Generated by 🧪 Daily Cli Tools Tester · sonnet46 · 68.8 AIC · ⌖ 13.9 AIC · ⊞ 9.4K · ◷
Problem Description
The
logstool consistently times out withError [0]: context deadline exceededwhen called without aworkflow_namefilter, even with minimal parameters (count: 1,max_tokens: 1000,start_date: "-6h").With a
workflow_namefilter, the same query completes in ~6–7 seconds.Tool
logsSteps to Reproduce
Call
logswithoutworkflow_name:Observe timeout at ~60 seconds:
Error [0]: context deadline exceededCall
logsWITHworkflow_name:Observe it completes successfully in ~6s.
Expected Behavior
Logs should be retrievable without specifying a workflow name. The
workflow_nameparameter is optional per the tool schema, so unfiltered queries should work (perhaps returning a subset).Actual Behavior
Any
logscall withoutworkflow_namehits a 60-second context deadline, regardless ofcount,max_tokens, orstart_datewindow size.Tested Variations (all timed out)
start_datecountmax_tokensworkflow_name-1d-1d-6h-7dab-testing-advisor-7ddaily-cli-tools-testerEnvironment
Impact
workflow_nameparameterRoot Cause Hypothesis
The unfiltered query likely triggers fetching/listing all workflow runs from the GitHub API without pagination limits applied server-side, causing the 60s MCP context deadline to expire before results arrive.