fix: stop applying the 45s SSE open timeout to non-streaming chat requests

[vibecoding-skills]

Problem

codewhale exec (plain, non---auto) against any non-streaming backend aborts with a misleading error whenever generation takes longer than 45 seconds:

Error: SSE stream request did not receive response headers after 45s. `codewhale doctor` can still
pass when non-streaming requests work; on Windows or proxy networks, try `DEEPSEEK_FORCE_HTTP1=1`
and rerun `codewhale`.

This makes plain exec effectively unusable with local models (Ollama, llama-server, vLLM without streaming) on any real-world prompt: short prompts finish under the wire, but e.g. a "rewrite this 300-line file" task is killed mid-generation. On the server side Ollama logs a canceled request (error reading llama-server chat response: context canceled).

Reproduction

codewhale --provider ollama --model <local model> exec "<prompt whose completion takes > 45s>"

Packet capture shows the request is delivered in full immediately; the client then closes the connection 45s later while the server is still generating. DEEPSEEK_FORCE_HTTP1=1 (which the error suggests) does not help — the transport is fine.

Cause

The bounded header wait was attached to the wrong path in crates/tui/src/client/chat.rs:

• create_message_chat — the non-streaming path (no "stream": true in the body) — wraps send_json_with_retry in tokio_timeout(stream_open_timeout(), …). But a non-streaming server only returns response headers after the entire generation completes, so the 45s "connection setup" budget races the model's full thinking + generation time. The doc comment on stream_open_timeout itself says the timeout "only covers connection setup and upstream header return, not model thinking time after streaming has started" — which is only true when streaming is actually requested.
• handle_chat_completion_stream — the SSE path the timeout was written for — had no open timeout at all, so the Windows/proxy header hang described in that comment was still unbounded there.

Fix

• create_message_chat now uses a non-streaming response budget: default 600s, overridable via CODEWHALE_NONSTREAM_TIMEOUT_SECS (clamped 30..3600), with an error message that explains that non-streaming servers legitimately hold the response for the whole generation.
• handle_chat_completion_stream now applies stream_open_timeout() to its header wait, as originally intended (existing 45s default and CODEWHALE_STREAM_OPEN_TIMEOUT_SECS override unchanged).
• Adds a clamp unit test for the new env override, mirroring stream_open_timeout_defaults_and_clamps_env_values.

Testing

• cargo check -p codewhale-tui clean
• cargo fmt applied; cargo clippy -p codewhale-tui --bin codewhale-tui clean
• cargo test -p codewhale-tui --bin codewhale-tui timeout — 53 passed, 0 failed (includes the new test)
• Manually verified against Ollama on macOS with a ~5k-token prompt whose completion takes several minutes: released 0.9.0 aborts at exactly 45s with the SSE error above (packet capture shows the client closing the connection mid-generation); a debug build of this branch runs the identical exec invocation for 2m42s and exits 0.

[github-actions]

Thanks @vibecoding-skills for taking the time to contribute.

This repository is observing a maintainer-managed PR intake gate in dry-run mode, so this pull request is staying open. This note helps maintainers prepare the allowlist before any enforcement is considered.

Please read CONTRIBUTING.md for the expected contribution shape. A maintainer can grant recurring PR access by commenting /lgtm on a pull request.

[Hmbown]

Thank you for this one, @vibecoding-skills — the analysis was correct, and it deserves a straight answer about why it is closing without merging.

Your report was accurate when you filed it. Both halves are now fixed on main by a374d196e ("refactor(client): share stream opening across wire adapters"):

1. The non-streaming path no longer carries the SSE open timeout. crates/tui/src/client/chat.rs:443, inside create_message_chat, is now a bare self.send_json_with_retry(&url, &body).await? — the tokio_timeout wrapper you identified is gone from exactly that spot.
2. The SSE path did keep a bounded open wait, which is the right outcome: stream_open_timeout() is now used at :477 in open_chat_stream_response, threaded through StreamOpenRequest. rg -n 'tokio_timeout' crates/tui/src/client/chat.rs shows only the import and the per-chunk idle timeout at :708.

So codewhale exec against Ollama or llama-server no longer dies at 45 s — which was the user-visible cost you were chasing.

Worth being explicit: an earlier triage pass of ours had this queued as an open bug to harvest. Re-checking against main overturned that. Your PR was right, our tracking was stale, and I'd rather say so than close this as if it had never been a real finding. I'm adding you to .github/AUTHOR_MAP so any future harvest in this area attributes to you.