The container harness ran nothing, and exited 0 doing it

[martin-k-m]

What was wrong

scripts/linux-check.sh inlined the script the container was to run into the docker run command line inside single quotes. One of its own comments reads:

    # The host target directory is another platform's and can be gigabytes.

The apostrophe in platform's closed the quoting. Substituting a docker that prints its argv shows what was actually asked for:

argv[15]='rust:1'
argv[16]='bash'
argv[17]='-c'
argv[18]='\n    # The host target directory is another platforms'
argv[19]='and'
argv[20]='can'
argv[21]='be'
argv[22]='gigabytes.'

The container ran bash -c on a single comment. bash executes a comment successfully and silently, so the exit status was 0. The tar, the rustup component add and exec cargo "$@" were never in the string — and neither were the caller's own arguments, which -- "$@" should have delivered.

scripts/linux-check.sh test --workspace returned success in under a second, having built and tested nothing.

Why it is the worst shape of defect in docs/BUGS.md

Every other silent failure in that file is Arc reporting success while not doing its job. This is the harness doing it, which is strictly worse, because the harness is what the other twelve were caught by. The Linux tracer cannot be built on macOS or Windows, so this script is the only gate the two Linux backends pass through on a developer machine. Every claim of a container run made through it is void.

I have not established how long it stood, and I am not going to guess a date I have not verified.

The fix is structural, not an escape

The container script is now scripts/linux-check-inner.sh, named on the command line as a path. No quoting of the outer command can truncate a file. Escaping the apostrophe would have fixed this instance and left the next comment free to do it again.

scripts/linux-verify.sh was already a file, for the full fixed pipeline, and is described as "run inside the container by linux-check.sh" — which it never was. The inline copy was a leftover of a half-finished extraction.

The inner script also sets user.email, user.name and init.defaultBranch, which several tests need and CI sets; the inline version never did, so the first genuinely-executed run would have failed on that instead.

Seen red first

All four cases in crates/arc-cli/tests/harness.rs failed against the old script, printing the argv above. They put a docker that records its arguments first on PATH, so they need neither Docker nor Linux and run on every platform. They assert that the caller's arguments arrive, that what is named is a script file rather than a comment, that no fragment of a comment appears as an argument, and that every script named exists and passes bash -n.

Gates run

Host (macOS): cargo fmt --all, cargo clippy --workspace --all-targets --all-features -- -D warnings clean, harness suite 4 passed.

Container, for the first time genuinely: bash scripts/linux-check.sh test --workspace --no-fail-fast in rust:1 on Docker Desktop (arm64, 12 CPUs). It now builds and runs the whole workspace, which takes minutes and prints hundreds of lines. 150 passed, 2 failed.

The two failures are on main's code and are not caused by anything here — they are concurrency tests, and both are of the shape docs/BUGS.md #12 already records for a contended container:

test concurrent_traced_runs_do_not_corrupt_dependency_metadata ... FAILED
test concurrent_traced_runs_stay_independent ... FAILED

Both fail on assert!(c.wait().unwrap().success()) and neither says anything more, because that assertion discards the child's status and output. That is the first thing the working harness found, and I am reporting it rather than folding it into this branch.

🤖 Generated with Claude Code