fix(install): bound curl connection setup with --connect-timeout 20#110657
fix(install): bound curl connection setup with --connect-timeout 20#110657xydigit-zt wants to merge 2 commits into
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 18, 2026, 11:57 PM ET / July 19, 2026, 03:57 UTC. Summary PR surface: Tests 0, Other +4. Total +4 across 4 files. Reproducibility: yes. at source level: curl documents that the existing low-speed controls do not apply to slow connects, while the submitted terminal transcript exercises a blackholed connection with the exact proposed flag set. The evidence establishes the relevant behavior, although this review did not independently execute the network scenario. Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Copy recommended automerge instructionNext step before merge
Security Review detailsBest possible solution: Land a rebased version that retains the symmetric 20-second connection bound in both curl helpers, preserves the existing 30-second low-speed transfer guard and retry behavior, and confirms the focused installer checks on the rebased head. Do we have a high-confidence way to reproduce the issue? Yes, at source level: curl documents that the existing low-speed controls do not apply to slow connects, while the submitted terminal transcript exercises a blackholed connection with the exact proposed flag set. The evidence establishes the relevant behavior, although this review did not independently execute the network scenario. Is this the best way to solve the issue? Yes. Adding curl’s connection-phase-specific timeout is the narrowest maintainable fix, and choosing 20 seconds aligns it with the existing wget sibling rather than introducing a separate installer policy. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against cc57514e680d. Label changesLabel justifications:
Evidence reviewedPR surface: Tests 0, Other +4. Total +4 across 4 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (13 earlier review cycles; latest 8 shown)
|
|
@clawsweeper re-review Repair commit pushed with stall-sensitive timeout fix. PR body updated with real behavior proof and terminal logs. |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
21ba7af to
feaad20
Compare
|
@clawsweeper re-review Rebased onto main and reduced scope: main already covers the post-connect stall window (30s), so this PR now only adds |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
feaad20 to
512b04a
Compare
The stall-sensitive --speed-limit/--speed-time options only apply after the connection is established, so a blackholed or unresponsive release host could still hang the installer indefinitely during connect. Add --connect-timeout 10 to both installer download helpers, mirroring the wget branch's --timeout=20 coverage of the connection phase, while keeping the existing 30-second low-speed grace window unchanged.
512b04a to
f6ecf09
Compare
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
Per review feedback: --connect-timeout covers DNS, TCP, and TLS setup, so a 10-second cutoff could fail valid slow connection establishment that the wget sibling (--timeout=20) still permits. Use 20 seconds in both curl helpers to match the wget connection window.
|
@clawsweeper re-review P2 addressed: both curl helpers now use |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@clawsweeper re-review |
What Problem This Solves
Scope reduced after rebase. Current
mainalready bounds post-connect stalls in both installer download helpers with--speed-limit 1 --speed-time 30(30-second low-speed grace window). This PR now adds only the remaining gap:--connect-timeout 20.The stall-sensitive
--speed-limit/--speed-timeoptions only take effect after the connection is established. If the release host is blackholed or unresponsive during connection setup (SYN sent, no reply), curl hangs in the connect phase indefinitely — blocking first-time installs andopenclawupgrades. The wget sibling already covers this phase via--timeout=20, which applies to connection establishment as well.Why This Change Was Made
download_fileis the core fetch path used for every asset the installers pull (Node, checksums, plugins). curl's timeout model splits into two phases:--connect-timeout— previously unbounded in the curl branch.--speed-limit 1 --speed-time 30(abort only if speed stays below 1 byte/s for 30 seconds).Adding
--connect-timeout 20bounds the connect phase without imposing any total download duration, so slow-but-progressing downloads remain unaffected. The existing 30-second low-speed grace window is preserved exactly as on main.User Impact
--timeout=20connection window) instead of hanging forever.--connect-timeout 20is a per-attempt limit; with the production--retry 3 --retry-delay 1, the download helper gives up after 4 bounded attempts in ~83 seconds (measured, Proof E) rather than blocking the installer indefinitely.Evidence
All runs use the exact flags now in
scripts/install.sh/scripts/install-cli.sh:--connect-timeout 20 --speed-limit 1 --speed-time 30(with-fsSL;--retryomitted in proofs so a single attempt is measured).Proof A — normal download succeeds
(
https://raw.githubusercontent.com/openclaw/openclaw/main/README.md)Proof B — slow but progressing download is NOT killed
Local server trickling 100 bytes at ~5 bytes/s (above the 1 byte/s threshold, transfer takes ~20s):
Proof C — post-connect stall is aborted at ~30s
Local server sends a partial body, then goes silent:
Proof D — blackholed connect is bounded by --connect-timeout 20
Non-routable address
10.255.255.1:81(proxy bypassed with--noproxy '*'so the connect phase itself is measured):Proof E — blackholed connect with the complete production command (incl. retries)
Endpoint: a local sink (
nc -k -l 18443) that accepts TCP but never answers the TLS handshake — a deterministic blackholed-connect stand-in (per the curl manual,--connect-timeoutcovers DNS + TCP + TLS setup, and--speed-limit/--speed-timedo not). Command is the exactdownload_filecurl invocation, including production retry options.Observed: 4 bounded attempts (1 + 3 retries, ~20s each) plus retry backoff; the helper fails deterministically in ~83 seconds instead of hanging forever. The same command without
--connect-timeoutstays blocked in the TLS-connect phase past a 45s outer guard (killed by harness), confirming the retry options alone cannot bound this phase.Regression tests
(The stubbed-curl assertions in both test files now require
--connect-timeout 20alongside the unchanged--speed-limit 1 --speed-time 30.)What was not tested
download_file; behavior proven at the exact-flag level above.--timeout=20already bounds connect).Summary of scope reduction: the original
--max-time 60/ 20s-stall-window versions of this PR are superseded by main's 30s stall-window fix. This PR is rebased onto main and now adds--connect-timeout 20(matching the wget branch's--timeout=20connection window, per review feedback) toscripts/install.shandscripts/install-cli.sh, plus matching test assertions.Complete-command runtime proof (curl --connect-timeout 20)
Both installer download helpers now emit the full bounded command (verified by
bash -nsyntax check + flag extraction):--connect-timeout 20matches the wget branch's--timeout=20connection window exactly, so both supported downloaders impose the same new connection-setup cutoff while retaining their existing retry behavior and the 30-second low-speed grace window. Upgrade-safe evidence covers the complete command, not just the delta flag.