An ad-hoc cargo command with --target-dir ends as t's error twice (store_io, then cache_unreachable): the given directory is taken as it stands #50

New issue

Open

opened 2026-11-12 22:42:55 +00:00 by xemmerling · 0 comments

xemmerling commented

2026-11-12 22:42:55 +00:00

Owner

Seen on t.tilo.so (86fa55c0) on 2026-11-12 at 22:37Z, in a person's session: one ad-hoc command, two jobs, both told as t's error.

The command, asked from tools/web/wasm-split of a checkout:

cargo build --quiet --release --locked --target-dir <checkout>/tools/web/wasm-split/../../../target/wasm-split-tool --message-format=json-render-diagnostics

First job, 28 s, cause store_io: "the node's store failed at the programs it built: cargo built /tools/web/wasm-split/../../../target/wasm-split-tool/release/wasm-split, outside the job's build directory: prefix not found" (src/node/run/left.rs, program_files).
Its rerun, 2 s, cause cache_unreachable: "the compiler cache failed the job: refused: /tools/web/wasm-split/../../../target/wasm-split-tool/release/build/crossbeam-deque-/out is not a plain path" (src/node/daemon/files.rs, plain).

The same build ran 17 more times that day without --target-dir: 15 passed, none erred. These two are the only ad-hoc cargo jobs of the day with a --target-dir, and the path is an absolute one on the asker's machine with .. parts.

So a target directory given on an ad-hoc cargo command is taken as it stands: cargo builds outside the job's build directory, the programs are not found under it, and the cache is handed a path with parent parts. Wanted, one of: the given directory is mapped onto the job's build directory, after resolving . and .. by the text, so the programs come back where the asker named them; or the command is refused before a job starts, as the asker's to change, with a line that says why. Never t's error. A failing test with this command line first.

Seen on t.tilo.so (86fa55c0) on 2026-11-12 at 22:37Z, in a person's session: one ad-hoc command, two jobs, both told as t's error. The command, asked from `tools/web/wasm-split` of a checkout: `cargo build --quiet --release --locked --target-dir <checkout>/tools/web/wasm-split/../../../target/wasm-split-tool --message-format=json-render-diagnostics` - First job, 28 s, cause `store_io`: "the node's store failed at the programs it built: cargo built <checkout>/tools/web/wasm-split/../../../target/wasm-split-tool/release/wasm-split, outside the job's build directory: prefix not found" (`src/node/run/left.rs`, `program_files`). - Its rerun, 2 s, cause `cache_unreachable`: "the compiler cache failed the job: refused: <checkout>/tools/web/wasm-split/../../../target/wasm-split-tool/release/build/crossbeam-deque-<hash>/out is not a plain path" (`src/node/daemon/files.rs`, `plain`). The same build ran 17 more times that day without `--target-dir`: 15 passed, none erred. These two are the only ad-hoc cargo jobs of the day with a `--target-dir`, and the path is an absolute one on the asker's machine with `..` parts. So a target directory given on an ad-hoc cargo command is taken as it stands: cargo builds outside the job's build directory, the programs are not found under it, and the cache is handed a path with parent parts. Wanted, one of: the given directory is mapped onto the job's build directory, after resolving `.` and `..` by the text, so the programs come back where the asker named them; or the command is refused before a job starts, as the asker's to change, with a line that says why. Never t's error. A failing test with this command line first.

xemmerling referenced this issue

2026-11-13 02:19:27 +00:00

node/admit: 7ef99e3f held CI out of the node while people used half of it on 11-12 (CI job starts 148 to 1.2 a minute); did not repeat on eeb2996a on 11-13, see the update #52

xemmerling referenced this issue

2026-11-14 08:44:33 +00:00

The compile cache handed four jobs a crate file their dependents were not built against (E0463, E0460), 21:54-21:58Z 11-13 #63