Skip to content

fix(llm): honour GRAPHIFY_API_TIMEOUT in the claude-cli backend, not just HTTP#1111

Closed
yaanfpv wants to merge 1 commit into
Graphify-Labs:v8from
yaanfpv:feat/cli-timeout
Closed

fix(llm): honour GRAPHIFY_API_TIMEOUT in the claude-cli backend, not just HTTP#1111
yaanfpv wants to merge 1 commit into
Graphify-Labs:v8from
yaanfpv:feat/cli-timeout

Conversation

@yaanfpv

@yaanfpv yaanfpv commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

Closes #1112.

GRAPHIFY_API_TIMEOUT, and the --api-timeout flag that sets it, only ever reached the OpenAI-compatible HTTP client. The two claude-cli subprocess calls, extraction (_call_claude_cli) and community labeling (the claude-cli branch of _call_llm), hardcoded timeout=600 and ignored the knob completely.

That bites on long claude-cli runs. A dense chunk or a large 1M-context model can legitimately run past ten minutes, and today there is no way to give it more headroom without editing the source. The HTTP backends already advertise the escape hatch (the env-var table documents it, and #792 wired it in); the CLI path just never picked it up.

What changed

  • Pulled the parse the HTTP path was doing inline into a small _resolve_api_timeout() helper, placed next to and mirroring the existing _resolve_max_tokens().
  • Routed all three call sites through it: the OpenAI client, _call_claude_cli (extract), and the claude-cli branch of _call_llm (labeling).
  • Updated the README env-var row so it no longer describes the timeout as HTTP-only.

The HTTP backend behaves exactly as before (same env var, same 600s default, same parsing). The claude-cli extraction and labeling subprocesses now respect GRAPHIFY_API_TIMEOUT, and since --api-timeout simply exports that env, the flag now applies to claude-cli as well. Non-positive or unparseable values fall back to 600s, matching the HTTP path.

Tests

Added to tests/test_claude_cli_backend.py: four unit tests for _resolve_api_timeout (default, env override, invalid string, non-positive) and two that assert the resolved value reaches subprocess.run's timeout= argument for both the default and an env override. The file passes (19 tests) and ruff check is clean.

…just HTTP

GRAPHIFY_API_TIMEOUT (and the --api-timeout flag that sets it) bounded only
the OpenAI-compatible HTTP client. The two claude-cli subprocess calls,
extraction and community labeling, hardcoded timeout=600 and ignored the knob
entirely, so a slow chunk on claude-cli could not be given more headroom
without patching the source.

Factor the parse the HTTP path already used into a _resolve_api_timeout helper
(mirroring _resolve_max_tokens) and route all three call sites through it.
Behaviour for the HTTP backend is unchanged. The claude-cli extraction and
labeling subprocesses now respect the same env var and flag, defaulting to
600s when unset and falling back to the default on non-positive or unparseable
values.
@safishamsi

Copy link
Copy Markdown
Collaborator

Implemented from our end in 75c4de7 with two additions over the PR: (1) the Anthropic SDK path (_call_anthropic) now also honours the timeout, so the README claim 'every backend' is accurate; (2) added a test for the _call_llm claude-cli branch separately from _call_claude_cli. Thanks for the diagnosis — your root cause analysis was exactly right.

@safishamsi safishamsi closed this Jun 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

claude-cli backend ignores GRAPHIFY_API_TIMEOUT and --api-timeout (hardcoded 600s)

2 participants