alkhttp/tasks/client/review-002-fwd15-stream-timeout.md

id, name, status, depends_on, scope, risk, impact, level, tags

id	name	status	depends_on	scope	risk	impact	level	tags
review-002-fwd15-stream-timeout	Subscriptions must not inherit the 30s total request timeout (FWD-15) + stream byte cap (FWD-14)	completed		moderate	medium	component	implementation	client review-002 adapters

Description

Review 002 FWD-15 [major] + FWD-14. Two streaming-path defects, same code region (src/adapters/forward.rs:824-934):

1. FWD-15: forward_stream sends through the shared client whose DEFAULT_REQUEST_TIMEOUT is 30 s — verified against reqwest 0.13.4 that the total-timeout sleep rides into the response body stream. A healthy subscription dies at 30 s with SSE stream error: operation timed out — even keep-alive-emitting sources (the gateway deliberately runs subscriptions unbounded per ADR-021; dispatch.rs:28). The outbound half of the same subscription is mortally capped.
2. FWD-14: the streaming branch has no size accounting — the 1 MiB cap bounds a single SSE line, not the stream. A hostile upstream emits well-formed 1-MiB-line events forever: 30 s of those is ~GB/s into envelope allocation (mitigated only by the timeout — which FWD-15's fix then removes, so both must land together or the fix makes FWD-14 worse).

Acceptance Criteria

• FWD-15: HandlerKind::Stream forwards send with request_timeout: None while keeping connect + read timeouts (implementer's choice: per-request extension override verified against reqwest 0.13, or a second derived client built from the same config minus the total timeout) — a >30 s healthy subscription survives
• FWD-15 wire test: responder trickling : keepalive comments past 30 s (scaled: use a configurable short client timeout in the test) → stream still delivering events after the old deadline
• FWD-14: a total byte cap on the streaming path (accumulate across feed; per-subscription total, default documented) and the line-cap check moved to before extend_from_slice so the overshoot cannot exceed cap + one chunk
• FWD-14 test: a stream exceeding the total cap terminates with a single terminal error envelope (the stream-ends semantics)
• Cap value + no-timeout decision documented in the module doc and http-server.md (ADR-049/021 note: unbounded time by design for subscriptions, bounded bytes per subscription)
• cargo test, cargo clippy --all-targets -- -D warnings, cargo fmt --check pass

References

• docs/reviews/002-post-remediation-review.md (Part D', FWD-14, FWD-15; Unit 2 rationale)
• src/adapters/forward.rs:824-934 (send + streaming branch), :969-1082 (SSE parser), http_client.rs:69-95/:149-150/:164-178 (timeout config + read-timeout doc claim)
• docs/architecture/decisions/049-streaming-handler-for-subscriptions.md
• tasks/client/review-001-client-timeout-retry.md (the timeout defaults this revises)

Notes

Order matters within this task: land FWD-15 with FWD-14 in the same commit-series — removing the total timeout without the byte cap opens an unbounded-memory window. The read-timeout (10/30 s stall guard) stays: it bounds upstream staleness; the doc at http_client.rs:149-150 already correctly describes read-timeout as the stall guard (the total timeout's "stalled upstream" claim there is the thing being fixed). Coordinate with review-002-cli01-retry-after-budget (same file) and review-002-client-policy-wire-tests (which should follow this to test the new behavior) — sequence those.

Summary

Derived timeout-less stream client (reqwest 0.13 cannot clear a client total timeout per-request, verified against source) + 1GiB total-bytes cap with pre-extend buffer check; over-cap streams end with one HTTP_413 terminal envelope. Wire tests for both arms.