[tech-debt] Give the recorder's upstream request a phase-aware timeout (ADR-010)

[dean0x]

Finding

Issue id: reliability-07
File:Line: e2e/capture/codex-recorder.ts:363-372

upstreamOptions sets neither timeout nor signal, and no
upstreamReq.setTimeout(...) is registered anywhere on the outbound request. An
upstream that completes the TCP handshake and then sends nothing leaves the handler
promise pending and the client response open indefinitely — an operation with no upper
bound.

Why Deferred

Unchanged, pre-existing lines. Choosing a timeout budget is a policy decision, not a
mechanical edit: ADR-010 requires that "a bound whose only effect is reclaiming a
provably dead connection stays; a bound that can terminate a request the origin was
about to answer ... is a defect." A Codex /responses stream can legitimately stay
silent for a long time, so the budget needs to be derived, not guessed — the
production leg needed three phase-specific budgets to get this right. That derivation is
out of scope for a capture-eligibility branch. The gap is newly observable (not newly
introduced) now that the factory is exported and exercised by the integration suite,
where it would otherwise present as an undiagnosed 30s test timeout.

Suggested Approach

Derive phase-aware timeout budgets for the recorder's upstream request (connect,
headers, inter-chunk idle) following the ADR-010 pattern used on the production leg, and
wire them via timeout/signal on upstreamOptions. Add a test with a deliberately
silent upstream that asserts a named, diagnosable failure rather than the generic
per-test timeout.

Provenance

Deferred from code review cycle 1 on PR #55 (branch feat/astra-sse-capture), review
directory .devflow/docs/reviews/feat-astra-sse-capture/2026-09-13_2137. Triage
disposition: FIX_SEPARATE.