Skip to content

fix: make cargo-binstall resilient to flaky build-host networks - #27

Merged
ChrisSc merged 1 commit into
mainfrom
fix/cargo-binstall-flaky-network
Jun 17, 2026
Merged

ChrisSc merged 1 commit into
mainfrom
fix/cargo-binstall-flaky-network

Conversation

@ChrisSc

@ChrisSc ChrisSc commented Jun 17, 2026

Copy link
Copy Markdown
Owner

Problem

make rebuild fails at stage 5/20 (install-tools.sh → cargo-binstall) on WSL2 / Docker Desktop, while the same build succeeds on macOS.

The failure looks like a slow network but is actually a latent defect:

  1. This host's WSL2/Docker-Desktop NAT chokes cargo-binstall's concurrent fetcher checks — ~20 simultaneous outbound connections is the measured ceiling. Resolving all 11 crates at once (~22 connections × GitHub + QuickInstall fetchers) tips over it, so the lookups time out (WARN resolve: Timeout reached while checking fetcher … deadline has elapsed, in 15s waves).
  2. With every binary fetcher exhausted, cargo-binstall falls back to compile-from-source — which hard-fails the build:
    • this image ships no Rust toolchain, and
    • the source path rejects --install-path:
      ERROR Fatal error:
        × For crate bottom: cargo-install does not support `--install-path`
      exit code: 100  →  make: *** [Makefile:21: rebuild] Error 1
      

macOS has no equivalent NAT layer, so it never trips the blip and never reaches the broken fallback.

Fix

Three guards on the cargo-binstall invocation, all no-ops on a healthy host (macOS unaffected):

  • --disable-strategies compile — never take the broken source-compile path. All 11 crates publish prebuilt binaries, so compile is never legitimately needed here.
  • Batches of 4 (~8 concurrent connections, well under the ~20 ceiling) instead of all 11 at once — addresses the root mechanism.
  • Retry each batch + --maximum-resolution-timeout 60 — rides out any residual transient NAT/DNS blip; the cargo cache mount keeps retries cheap.

Verification

  • Isolated BuildKit repro of the stage: 3 batches, ~2s each, zero timeouts, zero source fallback, all 11 binaries installed.
  • Full make rebuild: exit 0, image exported, claude-code Up (healthy).
  • shellcheck clean (the only CI gate this shell-script change touches; Dockerfile/YAML untouched).

🤖 Generated with Claude Code

On WSL2 / Docker Desktop the NAT chokes cargo-binstall's concurrent
fetcher checks (~20 simultaneous outbound connections is the observed
ceiling). Resolving all 11 crates at once (~22 connections) times out the
GitHub + QuickInstall lookups, and cargo-binstall then falls back to
compile-from-source — which hard-fails the build: this image ships no Rust
toolchain, and the source path rejects --install-path ("cargo-install
does not support --install-path", exit 100). macOS never trips the NAT
blip, so the build only failed on WSL.

Add three guards, all no-ops on a healthy host:
  * --disable-strategies compile — never take the broken source path (all
    11 crates publish prebuilt binaries, so compile is never needed here)
  * install in batches of 4 (~8 concurrent connections, well under the
    ceiling) instead of all 11 at once
  * retry each batch + --maximum-resolution-timeout 60 to ride out blips

Verified: full `make rebuild` green end-to-end, claude-code healthy;
shellcheck clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@ChrisSc
ChrisSc merged commit f695567 into main Jun 17, 2026
4 checks passed
@ChrisSc
ChrisSc deleted the fix/cargo-binstall-flaky-network branch June 17, 2026 02:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant