[cli-tools-test] 🐛 logs tool always times out after 60s — timeout parameter has no effect #47728

Problem Description

The logs MCP tool consistently fails with context deadline exceeded after exactly 60 seconds, regardless of the timeout parameter value passed. Every call to the logs tool results in a timeout, making the tool completely unusable.

Command/Tool

• Tool: logs
• MCP Server: agenticworkflows

Steps to Reproduce

1. Call logs with any parameters:

   printf '{"count":1,"max_tokens":1000}' | agenticworkflows logs .
   

2. Call with workflow_name filter:

   printf '{"workflow_name":"tidy","count":3,"max_tokens":3000}' | agenticworkflows logs .
   

3. Call with start_date range:

   printf '{"start_date":"-1d","count":3,"max_tokens":3000}' | agenticworkflows logs .
   

4. Call with explicit timeout parameter:

   printf '{"workflow_name":"tidy","count":3,"max_tokens":3000,"timeout":30}' | agenticworkflows logs .
   

All 4 variants fail after exactly 60 seconds.

Expected Behavior

• logs downloads workflow run logs and returns them within the allotted timeout.
• The timeout parameter should be respected, allowing callers to set a shorter deadline.
• At minimum, count:1 with a specific workflow_name should succeed well within 60 seconds.

Actual Behavior

Every logs call hits a 60-second hard deadline and returns:

Error [0]: context deadline exceeded

The timeout parameter has no observable effect — the tool still times out at exactly 60s whether timeout:30 or no timeout is set.

Environment

• Repository: github/gh-aw
• Run ID: 30071179989
• Date: 2026-07-24
• Test runner: Daily CLI Tools Exploratory Tester

Impact

• Severity: Critical
• Frequency: Always (100% reproduction rate across all tested parameter combinations)
• Workaround: None — audit with a known run ID still works. logs is completely non-functional.

Diagnostics

Observations from MCP keepalive logs:

• MCP connection initializes in ~30ms ✅
• Keepalive pings respond correctly every 10s ✅
• After exactly 5 keepalive pings (50s elapsed + 10s more = 60s), the tools/call returns with elapsed=60023ms and context deadline exceeded
• The timeout parameter value (e.g., 30) does NOT reduce the wait — tool still waits 60s before failing

This suggests the 60s is a hardcoded server-side context deadline that ignores the timeout input parameter.

Additional Context

• audit (with known run_id) works correctly and completes in ~300ms–2s ✅
• compile works correctly (~1.4s for 3 workflows) ✅
• status works correctly ✅
• Only logs is broken

The timeout parameter description in --help shows it as an available option, but the server-side implementation appears to use a fixed 60s context deadline instead of the caller-supplied value.

Generated by 🧪 Daily Cli Tools Tester · sonnet46 · 41.7 AIC · ⌖ 11.9 AIC · ⊞ 9.4K · ◷

• expires on Jul 30, 2026, 10:14 PM UTC-08:00