Skip to content

[cli-tools-test] logs tool: engine filter query exceeds default timeout (context deadline exceeded) #51952

Description

@github-actions

Problem Description

The agenticworkflows logs MCP tool times out with context deadline exceeded when filtering by engine (e.g. engine: "claude") even with a small count. The default timeout appears to be 60s, which is insufficient for engine-filtered queries — the underlying implementation likely has to scan/paginate through many workflow runs to find ones matching the engine rather than filtering more efficiently.

Command/Tool

  • Tool: logs (agentic-workflows MCP server)
  • Command:
    printf '{"engine":"claude","count":2,"max_tokens":3000}' | agenticworkflows logs .
    

Steps to Reproduce

  1. Call the logs tool with engine: "claude" and count: 2 (default timeout, no explicit timeout param).
  2. Observe the call runs for the full 60s and fails.
  3. Retry the same query with timeout: 300 explicitly set — it succeeds in ~30s.

Expected Behavior

Engine-filtered log queries with a small count (e.g. 2) should complete well within the default timeout, similar to unfiltered or workflow_name-filtered queries which typically complete in 6-11s.

Actual Behavior

With default timeout, the call errors out after 60s with:

Error [0]: context deadline exceeded

Retrying with timeout: 300 succeeds after ~30s, confirming the query itself works but the default timeout budget is too aggressive for engine-filtered queries.

Environment

  • Repository: github/gh-aw
  • Run ID: 31461891659
  • Date: 2026-08-11

Impact

  • Severity: Medium
  • Frequency: Likely always for engine-filtered queries against a repo with many workflow runs (this repo has 284 workflows across 12 engines)
  • Workaround: Explicitly pass a higher timeout (e.g. timeout: 300) when using the engine filter.

Additional Context

Other logs filters tested (workflow_name, start_date incl. future dates, nonexistent workflow name) all completed quickly (<11s) and returned clear, well-formed results/error messages. Only the engine filter exhibited this default-timeout issue. Consider raising the default timeout for engine-filtered queries, optimizing the underlying scan (e.g. using GitHub Actions workflow-run list filters server-side), or adding partial/streaming results before the deadline.

A minor, non-blocking usability gap was also found: the compile tool's --help text does not clarify that workflows must be an array (passing a plain string yields a JSON-schema validation error: type: ... has type "string", want one of "null, array"). Adding an example with array syntax to the help text would prevent this trial-and-error.

Generated by 🧪 Daily Cli Tools Tester · auto · 48.2 AIC · ⌖ 5.2 AIC · ⊞ 13.5K ·

  • expires on Aug 17, 2026, 9:42 PM UTC-08:00

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions