Thanks, cubic found that timeout: '0' would schedule the new connect timer immediately. Fixed in 432a4d8 by only starting the wall-clock timer for parsed timeouts greater than 0 and added regression coverage for disabled timeout: '0'. @cubic-dev-ai please re-run.

Thanks, cubic found that timeout: '0' would schedule the new connect timer immediately. Fixed in 432a4d8 by only starting the wall-clock timer for parsed timeouts greater than 0 and added regression coverage for disabled timeout: '0'. @cubic-dev-ai please re-run.

@cyphercodes I have started the AI code review. It will take a few minutes to complete.

Thanks for the PR @cyphercodes,

This is a clean fix, and the analysis matches what I was expecting from the issue. I am happy to land it. Two small things, before I merge:

1. Duplicate timer on the native path. In lib/adapters/http.js around line 1047, when isNativeTransport && timeout > 0 we now arm the wall clock timer and still register req.setTimeout(timeout, handleRequestTimeout) after it. The wall clock will almost always pre-empt, so the second registration is mostly vestigial in this branch. Worth either skipping it when the wall clock is armed, or routing both through a single handler. Cleanup, not a bug.

2. Defensive clear in onFinished. The req.once('close', ...) handler covers the cleanup today, but a clearConnectPhaseTimer() inside onFinished would future-proof against any reordering of close vs settle. Optional.

One thing I want to call out, so it is on the record: this changes time to first byte semantics on the maxRedirects === 0 path. After the connection succeeds, the wall clock is cleared in handleResponse, so streamed bodies are still governed by the existing req.setTimeout inactivity logic, which is what I want. Just confirming that was intentional and not an accident of where the clear landed.

Let me know when the PR has been updated, and I will take a look again

Updated this PR to address the two follow-ups:

• Reused a single timeout handler for both the native connect-phase wall-clock timer and ClientRequest#setTimeout.
• Added a defensive clearConnectPhaseTimer() inside onFinished() as well.

Local verification:

• npm ci ✅
• npx eslint lib/adapters/http.js ✅
• npx vitest run --project unit tests/unit/adapters/http.test.js -t "timeout property during TCP connect|timeout set to zero during TCP connect" ✅
• git diff --check ✅

I also ran the full npx vitest run --project unit tests/unit/adapters/http.test.js; the two targeted timeout tests passed, but the full file still had two unrelated local/environment-sensitive failures (DNS > should handle errors timed out resolving no-such-domain-987654.com, and one HTTP2 session test errored with Premature close).