[argszero]

Summary

The gateway's outbound HTTP client was built with .timeout(120s), and the streaming forward used that same client. .timeout() in reqwest is a total request deadline — it wraps the response body too — so an SSE stream that keeps producing data was killed at 120 s wall-clock and the client saw error decoding response body (a timeout reported as a decode failure).

Reproduced with a fake upstream dripping one SSE frame every 30 s (6 frames, ~180 s planned), driven through the real router and the real AppState::new:

PROBE headers status=200 OK at 2.409375ms
PROBE chunks=3 last_chunk_at=90.011245167s saw_done=false err="error decoding response body" total=120.004955084s

Only 3 of 6 frames arrived, [DONE] never did, and the call ended at exactly 120.005 s. Long answers and reasoning models routinely exceed 120 s, so this truncated normal traffic.

read_timeout() — the per-read deadline that resets after every successful read, i.e. the semantics streaming actually wants — was never set anywhere in the tree, so the streaming path had stall detection and a total cap where it should have had only the former.

Related Issue

None — no issue exists for this. Reported as a runtime reproduction in the PR body instead.

Changes

• src/routes/mod.rs: one policy number (UPSTREAM_TIMEOUT, the 120 s the code already used) plus two explicit constructors — upstream_client(timeout) keeps the total deadline for non-stream responses, and upstream_stream_client(timeout) uses connect_timeout(timeout).read_timeout(timeout) with no total deadline (progress is never punished; 120 s of silence still is). AppState gains http_stream alongside http.
• src/gateway.rs: forward_stream's two outbound call sites now use st.http_stream. forward (non-stream) is unchanged.
• No configuration or data-structure change, so config/config.example.toml is untouched.

Tests

• cargo test — 207 passed (205 before; +2 new tests)
• cargo fmt --check — clean
• cargo clippy --all-targets -- -D warnings — clean
• New unit tests added

The pair drives a fake upstream that drips 15 SSE frames 100 ms apart (~1.5 s), then a usage frame and [DONE], through the real router:

• sse_slow_stream_survives_a_read_timeout — with the production stream factory at a 200 ms limit (≪ the 1.5 s stream) the stream must arrive complete (all 15 frames + [DONE]) and settle once;
• sse_slow_stream_is_cut_by_a_total_deadline — with the non-stream factory (a total deadline at 200 ms, i.e. the pre-fix behaviour) the stream must be truncated and must not settle. This arm also proves the gateway really reads st.http_stream: had it still read st.http, nothing would truncate.

Both arms use the production constructors, so the real construction is exercised — only 200 ms instead of 120 s.

A/B with teeth (each mutation injected alone, both restored byte-identically):

mutation	expected red	observed
forward_stream back on st.http (pre-fix behaviour)	truncation test	passed=1 failed=1 red=[sse_slow_stream_is_cut_by_a_total_deadline]
stream factory keeps a total deadline	survival test	passed=1 failed=1 red=[sse_slow_stream_survives_a_read_timeout]

Checklist

• Branch name follows the convention (fix/stream-total-timeout)
• Commit message uses Conventional Commits
• Single responsibility, minimal change (2 production lines + tests)

Notes / scope

• Not a money change: billing reads the upstream usage, and the non-stream path is untouched. The truncated call is not billed either — fwd.chain(finalize) never polls finalize after a body error. That is the same shape as the existing sse_client_disconnect_skips_settle test (settling without upstream usage is deliberately not implemented, and this PR does not change that).
• Still-open question left alone on purpose: the non-stream 120 s total deadline stays as is — it bounds a hung upstream.