[cli-tools-test] agenticworkflows MCP: `logs` and `audit` tools always fail with context deadline exceeded at 60s

[github-actions]

Warning

threat detection engine error
The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.

Details

The threat detection engine failed to produce results.

Review the workflow run logs for details.

Problem Description

Both the logs and audit tools of the agentic-workflows MCP server consistently fail with Error [0]: context deadline exceeded after exactly ~60016ms, regardless of the requested scope or the explicit timeout parameter. compile and status work fine and return quickly (compile: 829ms-1.2s per workflow, 30.6s for all 266 workflows; status: ~6.4s).

Command/Tool

• Tool: logs, audit
• Commands tried:
  • printf '%s' '{"start_date":"-1d","count":3,"max_tokens":3000}' | agenticworkflows logs .
  • printf '%s' '{"start_date":"-1d","count":3,"max_tokens":3000,"timeout":120}' | agenticworkflows logs .
  • printf '%s' '{"run_id":30608011633,"max_tokens":3000}' | agenticworkflows audit .

Steps to Reproduce

1. Call the logs tool with start_date: "-1d", count: 3, max_tokens: 3000 (token-efficient params per guidance).
2. Observe the call hangs until ~60s, then fails.
3. Retry with an explicit timeout: 120 param - the call still fails at exactly 60016ms, showing the client-supplied timeout is not honored (or a separate 60s deadline is enforced upstream of it).
4. Call audit with a valid run_id (the current workflow run, 30608011633) - same failure at 60016ms.
5. Calling audit with an invalid/nonexistent run_id (e.g. 1 or 30500000000) returns quickly (~320-370ms) with a clean, helpful JSON error (workflow run N not found ... suggestions: [...]), confirming the audit/logs backend itself is reachable and the timeout is specific to real/longer-running queries.

Expected Behavior

The logs and audit tools should either:

• Complete within the request's own bounds when a valid timeout is supplied, or
• Return a clear, structured error indicating the operation needs more time / a smaller scope, rather than a generic context deadline exceeded after a fixed ~60s regardless of parameters.

Actual Behavior

Every logs/audit call against real data times out at exactly 60016ms (MCP tools/call: status=200, elapsed=60016ms, followed by Error [0]: context deadline exceeded), even when parameters are minimized (count:3, max_tokens:3000) or when an explicit longer timeout (120) is passed. This suggests a hardcoded ~60s deadline somewhere in the MCP bridge/gateway (awmg-mcpg) that is not connected to the tool's own timeout parameter.

Environment

• Repository: github/gh-aw
• Run ID: 30608011633
• Date: 2026-07-31
• Tools involved: agentic-workflows MCP server (logs, audit), bridge awmg-mcpg

Impact

• Severity: High - logs and audit are two of the three primary tools this daily tester is meant to exercise, and both are completely non-functional against real workflow runs.
• Frequency: Always (100% reproduction across 3 separate attempts: 2x logs, 1x audit with a valid run).
• Workaround: None found. Reducing count/max_tokens did not help. Passing an explicit timeout param did not help - the failure occurs at the same 60016ms mark every time.

Logs/Diagnostics

[info] [agenticworkflows] MCP tools/call: tool=logs, args={"start_date":"-1d","count":3,"max_tokens":3000,"timeout":120}
[info] [agenticworkflows] MCP keepalive ping: id=1000..1004 (5 pings, ~10s apart)
[info] [agenticworkflows] MCP tools/call: status=200, elapsed=60016ms
[info] [agenticworkflows] MCP keepalive stopped
[info] [agenticworkflows] Tool call complete: total=60045ms
Error [0]: context deadline exceeded
[error] [agenticworkflows] Tool call error: Error [0]: context deadline exceeded

Same pattern for audit with run_id:30608011633.

Additional Context

• compile and status tools work correctly and quickly through the same MCP bridge, so the bridge itself is not universally broken - the issue appears specific to the logs/audit code path (possibly a slow log-fetch step that isn't respecting client timeout, or a gateway-level deadline shorter than the operation needs).
• audit with an invalid run_id returns in ~350ms with a good error, so the slowness is specific to real data fetching, not tool dispatch overhead.

Test Summary (other phases)

• Phase 1 (status): Works. Enumerated 266 workflows in ~6.4s, all reporting compiled: Yes.
• Phase 2 (logs): Failed - see above. Could not proceed to log content analysis, filtered queries, or edge cases requiring successful downloads.
• Phase 3 (audit): Failed for real runs - see above. Invalid-run-id edge case behaves correctly.
• Phase 4 (compile): Fully passed. Tested ci-doctor (829ms) and smoke-copilot (1.17s) individually, then bulk-compiled all 266 workflows in 30.6s with 0 errors/warnings.
• Phases 5-7: Blocked by the logs/audit failures; integration and performance testing for those two tools could not be completed.

Generated by 🧪 Daily Cli Tools Tester · auto · 43.8 AIC · ⊞ 13.4K · ◷

• expires on Aug 6, 2026, 10:05 PM UTC-08:00

[github-actions]

This issue was automatically closed because it expired on 2026-08-07T06:05:26.021Z.

Closed by Workflow