Summary
GRAPHIFY_API_TIMEOUT (and the --api-timeout flag that sets it) has no effect on the bedrock backend. A long generation is cut off at botocore's 60s default read timeout and fails with Read timeout on endpoint URL, no matter how high the timeout is set.
Reproduction
GRAPHIFY_API_TIMEOUT=1800 \
GRAPHIFY_BEDROCK_MODEL=global.anthropic.claude-opus-5 \
GRAPHIFY_LLM_TEMPERATURE=none \
AWS_PROFILE=<your-profile> \
graphify .
...
[graphify] chunk 2/3 failed: Read timeout on endpoint URL: "https://bedrock-runtime.us-east-1.amazonaws.com/model/global.anthropic.claude-opus-5/converse"
[graphify] chunk 1/3 failed: Read timeout on endpoint URL: "https://bedrock-runtime.us-east-1.amazonaws.com/model/global.anthropic.claude-opus-5/converse"
[graphify] WARNING: 2/3 semantic chunk(s) failed — see errors above. Partial results returned.
Large doc chunks on a slow opus-class model routinely generate for longer than 60s. Converse is non-streaming, so the whole response has to finish before the first byte arrives; small chunks squeak in under 60s while large ones time out — even with GRAPHIFY_API_TIMEOUT raised well past the generation time.
Root cause
Both bedrock-runtime clients are constructed with no botocore config: the primary extraction path (_call_bedrock) and the secondary dispatch path (the bedrock branch of _call_llm). With no config=, boto3 uses botocore's default read_timeout of 60s and never sees GRAPHIFY_API_TIMEOUT. The env var only ever reached the OpenAI/Anthropic HTTP clients and, later, the claude-cli subprocess — _resolve_api_timeout() is simply never applied to the boto3 clients.
The README env-var table advertises GRAPHIFY_API_TIMEOUT as general, which makes the Bedrock gap easy to trip over.
Suggested fix
Build both Bedrock clients with an explicit botocore.config.Config that wires read_timeout to _resolve_api_timeout(), mirroring how the other backends already consume it. This is the same class of gap that was closed for the claude-cli subprocess (#1112 / #1111) and the secondary LLM dispatch path (#1442); Bedrock is the last cloud backend still ignoring the knob.
Not a duplicate of #1112 (that issue is the claude-cli subprocess hardcoding timeout=600) or #1442 (the OpenAI/Anthropic clients in the secondary dispatch path missing timeout=) — both are non-Bedrock paths, and neither touches boto3 client construction, which has its own separate read_timeout default that no env var reaches.
Summary
GRAPHIFY_API_TIMEOUT(and the--api-timeoutflag that sets it) has no effect on thebedrockbackend. A long generation is cut off at botocore's 60s default read timeout and fails withRead timeout on endpoint URL, no matter how high the timeout is set.Reproduction
Large doc chunks on a slow opus-class model routinely generate for longer than 60s. Converse is non-streaming, so the whole response has to finish before the first byte arrives; small chunks squeak in under 60s while large ones time out — even with
GRAPHIFY_API_TIMEOUTraised well past the generation time.Root cause
Both
bedrock-runtimeclients are constructed with no botocore config: the primary extraction path (_call_bedrock) and the secondary dispatch path (thebedrockbranch of_call_llm). With noconfig=, boto3 uses botocore's defaultread_timeoutof 60s and never seesGRAPHIFY_API_TIMEOUT. The env var only ever reached the OpenAI/Anthropic HTTP clients and, later, the claude-cli subprocess —_resolve_api_timeout()is simply never applied to the boto3 clients.The README env-var table advertises
GRAPHIFY_API_TIMEOUTas general, which makes the Bedrock gap easy to trip over.Suggested fix
Build both Bedrock clients with an explicit
botocore.config.Configthat wiresread_timeoutto_resolve_api_timeout(), mirroring how the other backends already consume it. This is the same class of gap that was closed for theclaude-clisubprocess (#1112 / #1111) and the secondary LLM dispatch path (#1442); Bedrock is the last cloud backend still ignoring the knob.Not a duplicate of #1112 (that issue is the
claude-clisubprocess hardcodingtimeout=600) or #1442 (the OpenAI/Anthropic clients in the secondary dispatch path missingtimeout=) — both are non-Bedrock paths, and neither touches boto3 client construction, which has its own separateread_timeoutdefault that no env var reaches.