Provider timeout is a socket-inactivity timer, not a wall-clock deadline #151

New issue

Closed

opened 2026-08-15 14:33:48 +00:00 by john · 0 comments

john commented

2026-08-15 14:33:48 +00:00

Owner

Source: deep dive F11 (deadline half); general scan recommendation 4
Verdict: DISPUTE - overstated, closing

Claim as reviewed

The timeout supplied to https.request is a socket inactivity timer, not a wall-clock deadline. A server or intermediary can send occasional bytes indefinitely, and the workflow documentation wrongly describes this as capping total thinking time.

At HEAD `f354864` (v3.3.0)

The mechanism reading is correct - cadence-core/bin/review-provider.mjs:512-536 sets timeout on the request, which is socket inactivity.

The documentation charge is not. cadence-core/references/review-triggers.md:238-248 states it precisely: "the bound is a socket INACTIVITY timeout on an unstreamed response, so it caps total thinking time rather than detecting a dead connection." That reasoning is correct - on an unstreamed response, inactivity is total elapsed time. Both review passes cited this file and read past the sentence.

Note

Defeating the bound requires a provider that drips bytes on a response documented as unstreamed. The size half of the finding is real and is filed separately as an open issue.

**Source:** deep dive F11 (deadline half); general scan recommendation 4 **Verdict:** DISPUTE - overstated, closing ### Claim as reviewed The timeout supplied to `https.request` is a socket inactivity timer, not a wall-clock deadline. A server or intermediary can send occasional bytes indefinitely, and the workflow documentation wrongly describes this as capping total thinking time. ### At HEAD f354864 (v3.3.0) The mechanism reading is correct - `cadence-core/bin/review-provider.mjs:512-536` sets `timeout` on the request, which is socket inactivity. The documentation charge is not. `cadence-core/references/review-triggers.md:238-248` states it precisely: "the bound is a socket INACTIVITY timeout on an unstreamed response, so it caps total thinking time rather than detecting a dead connection." That reasoning is correct - on an unstreamed response, inactivity is total elapsed time. Both review passes cited this file and read past the sentence. ### Note Defeating the bound requires a provider that drips bytes on a response documented as unstreamed. The size half of the finding is real and is filed separately as an open issue.