The launch trend has published nothing since the Rust cutover: the benched dl cannot see devpod

[blooop]

Question

The trend this map exists to keep has published nothing since the Rust cutover, and the map's destination — "a developer asking 'did launch get slower, and in whose stage?' reads a chart instead of re-measuring by hand" — is currently unmet. Restore it, and pin it so it cannot stop silently again.

The failure, reproduced across every run since it started. Four consecutive bench.yml runs have failed at the Prime the image and the clone cache step, all identically:

devpod not found on PATH: dl cannot manage workspaces without it.
##[error]Process completed with exit code 127.

Runs 32408082164 (PR #287), 32412563930 (#288), 32413008368 (#289), 32415797124 (#290). The last green run is 32407778417 (#286).

The mechanism, and it is one line of the fix that broke it. 1654daf (PR #287, "Retire the Python tree and the parity harness") correctly stopped the trend measuring the Python build — it replaced pixi run dl with pixi run build-release plus a symlink onto $GITHUB_PATH:

ln -sf "$PWD/rust/target/release/dl" /tmp/dl-bench/bin/dl

That is the right binary and the right profile, and it is exactly why the step now fails. dl shells out to a bare devpod resolved from PATH, and devpod is deliberately not installed on the runner — it is a pixi dependency (devpod = ">=0.26.1,<0.27"), so it lives only inside the pixi environment, and bench.yml says so in the comment above the setup-pixi step: "No devpod install step: devpod is a pixi dependency, already in the lockfile setup-pixi restores." Under the old pixi run dl that held, because the wrapper put the environment on PATH. A bare symlink does not, so dl runs with no devpod at all.

The fix has a constraint that rules out the obvious one. Re-wrapping the timed command in pixi run would put pixi's own startup inside the number this trend publishes — the very reason #287 used a bare symlink, and the reason the same comment says pixi run dl is "deliberately not used below". So devpod has to reach PATH beside dl rather than by wrapping the launch: symlinking the environment's own devpod into /tmp/dl-bench/bin alongside it keeps both the pinned version and the un-wrapped measurement. Whatever shape it takes, the step that primes and the steps that time must resolve the same devpod, and it must be the lockfile's.

Pin it. test_bench_workflow.py already holds the charter's properties down (alert-don't-gate, separate file, no paths: filter). This class of breakage — the benched dl cannot see a tool it shells out to — is what it should hold next, so the fix cannot be undone by the next person who touches how dl gets onto PATH.

One thing to record when it goes green, not to fix. All 35 published points measure the Python build: the trend started 2026-08-15, the cutover shipped 0.1.0 on 2026-08-19, and until 1654daf these steps ran the console script the editable Python install left in the environment — bench.yml's own comment calls this out ("this trend was measuring the Python build while the released dl was Rust, and nothing said so"). So the first successful run publishes the first Rust point, and it lands against a Python baseline: the action compares each point to the immediately previous one only (#197), so that single comparison is implementation-change plus whatever moved, and any alert it raises means nothing. Name the commit of the first Rust point in the map's Decisions-so-far so nobody later reads the step as a regression.

[blooop]

Fixed by PR #373: devpod is symlinked onto the same PATH the benched dl runs from, pinned three ways in test/test_bench_workflow.py. The trend is demonstrably restored: bench.yml has run green on every main merge since, through 0.20.0 on 2026-08-26, so points are publishing again. The one thing this ticket asked to record rather than fix, naming where the Rust points begin, goes into map #193's body, which is being updated alongside this close.