[cli-tools-test] [bug] `logs` tool times out with `context deadline exceeded` when no `workflow_name` filter is provided

[github-actions]

Problem Description

The logs MCP tool consistently times out after exactly 60 seconds with context deadline exceeded when called without a workflow_name filter, even with a short start_date range and low count. The tool has a hard 60s server-side timeout that triggers before any log data is returned.

Command/Tool

• Tool: logs
• MCP server: agenticworkflows

Steps to Reproduce

1. Call logs without a workflow_name filter:

   {"start_date":"-1d","count":3,"max_tokens":3000}
   

2. Also fails with a shorter range:

   {"start_date":"-6h","count":2,"max_tokens":2000}
   

Expected Behavior

Logs download within the timeout, or return a helpful error if the query is too broad.

Actual Behavior

After exactly 60 seconds:

Error [0]: context deadline exceeded

The elapsed time is consistently 60014ms or 60011ms.

Contrast: Filtered Calls Work

When workflow_name is specified, the tool returns in ~6.3s. When engine is set to an invalid value, it fails in 70ms with a clear validation error. So the issue is specific to the unfiltered path.

Environment

• Repository: github/gh-aw
• Run ID: 29984114651
• Date: 2026-07-23

Impact

• Severity: High
• Frequency: Always (100% reproducible)
• Workaround: Always specify workflow_name to scope the query

Diagnostics

[info] MCP tools/call: tool=logs, args={"start_date":"-1d","count":3,"max_tokens":3000}
[info] MCP keepalive ping: id=1000 ... id=1004 (5 pings at 10s intervals)
[info] MCP tools/call: status=200, elapsed=60014ms
Error [0]: context deadline exceeded

Root Cause Hypothesis

The unfiltered query likely lists all workflow runs across all 261 workflows in the repository, which takes longer than the 60s server timeout. The count parameter is not applied early enough to bound the backend query.

Generated by 🧪 Daily Cli Tools Tester · sonnet46 40.9 AIC · ⌖ 8.56 AIC · ⊞ 9.4K · ◷

• expires on Jul 29, 2026, 10:18 PM UTC-08:00