Problem Description
The logs MCP tool consistently times out with context deadline exceeded after exactly 60 seconds when called without a workflow_name filter. The timeout parameter does not extend the deadline (tested with timeout: 120).
Command/Tool
- Tool: logs
- Command:
logs with {"start_date":"-1d","count":3,"max_tokens":3000} (no workflow_name)
Steps to Reproduce
- Call the
logs tool without a workflow_name filter:
{"start_date": "-1d", "count": 3, "max_tokens": 3000}
- Observe that after exactly 60 seconds it returns
context deadline exceeded.
- Retry with
timeout: 120 — same result, still fails at 60s.
Expected Behavior
The tool should return logs for recent runs across all workflows (limited by count), or the timeout parameter should extend the server-side context deadline.
Actual Behavior
MCP tools/call: status=200, elapsed=60016ms
Error [0]: context deadline exceeded
Consistently fails at ~60 seconds regardless of timeout value.
Workaround
Specifying a workflow_name filter avoids the timeout. E.g., workflow_name: "poem-bot" completes in ~1s. The issue only occurs for unfiltered (all-workflows) queries.
Secondary Finding: Workflow Name Resolution Bug
When calling logs with workflow_name: "smoke-ci" (a valid workflow file), it fails with:
could not find any workflows named Smoke CI
The tool appears to title-case the workflow ID to find the GitHub Actions display name, but smoke-ci.md has a different display name in its frontmatter. Workflows with display names that happen to match (e.g., poem-bot -> Poem Bot) succeed, while others fail.
Environment
- Repository: github/gh-aw
- Run ID: 30190589855
- Date: 2026-07-26
- gh-aw version: 1.0.75 (firewall v0.27.41)
Impact
- Severity: High
- Frequency: Always (100% reproducible)
- Workaround: Use
workflow_name with the exact display name (not file ID) for individual workflows; no workaround for unfiltered queries
References: Run 30190589855
Generated by 🧪 Daily Cli Tools Tester · sonnet46 · 75.4 AIC · ⌖ 7.26 AIC · ⊞ 9.4K · ◷
Problem Description
The
logsMCP tool consistently times out withcontext deadline exceededafter exactly 60 seconds when called without aworkflow_namefilter. Thetimeoutparameter does not extend the deadline (tested withtimeout: 120).Command/Tool
logswith{"start_date":"-1d","count":3,"max_tokens":3000}(noworkflow_name)Steps to Reproduce
logstool without aworkflow_namefilter:{"start_date": "-1d", "count": 3, "max_tokens": 3000}context deadline exceeded.timeout: 120— same result, still fails at 60s.Expected Behavior
The tool should return logs for recent runs across all workflows (limited by
count), or thetimeoutparameter should extend the server-side context deadline.Actual Behavior
Consistently fails at ~60 seconds regardless of
timeoutvalue.Workaround
Specifying a
workflow_namefilter avoids the timeout. E.g.,workflow_name: "poem-bot"completes in ~1s. The issue only occurs for unfiltered (all-workflows) queries.Secondary Finding: Workflow Name Resolution Bug
When calling
logswithworkflow_name: "smoke-ci"(a valid workflow file), it fails with:The tool appears to title-case the workflow ID to find the GitHub Actions display name, but
smoke-ci.mdhas a different display name in its frontmatter. Workflows with display names that happen to match (e.g.,poem-bot->Poem Bot) succeed, while others fail.Environment
Impact
workflow_namewith the exact display name (not file ID) for individual workflows; no workaround for unfiltered queriesReferences: Run 30190589855