The wine blocking job flaked with ERR_PNPM_ENOENT rename '_tmp_*' ->
'<pkg>/node_modules/esbuild' during workspace snapshot + pnpm install
(runs 30334004123 and 30340039598), and a plain rerun passed. Root
cause is upstream pnpm/pnpm#12880: the hoisted linker's parallel
linkers race to rename their _tmp_* staging directory onto the same
nested package path, and the loser exits although an identical
re-install succeeds. Only this lane uses nodeLinker: hoisted, so only
this lane hits it.
snapshot_and_install now retries exactly that log signature up to two
times, wiping the scratch tree's node_modules first (the snapshot
itself contains none, so the wipe restores the pre-install state) and
logging each retry with the upstream issue. Any other install failure
still fails on the first attempt, and a race that survives the final
attempt still fails loud with the install log tail.
sha256sum-or-shasum selection happens in preflight (macOS ships shasum,
not GNU coreutils) with a clear missing-tool hint; provisioning now waits
for every child and reports each named status before exiting, so a fast
failure can neither hand the EXIT trap a scratch tree that a still-running
install is writing into nor bury the root cause behind a downstream
symptom.
scripts/wine-windows-gates.sh owns the whole lane — workspace snapshot,
concurrent Node/wineboot/install provisioning, entrypoint resolution, the
vue link, smoke, and the two concurrent blocking gates — so the ci.yml
windows job shrinks to runner provisioning plus one script call, and
pnpm run check:windows-wine runs the identical script locally. The local
path never mutates the working tree, persists the Wine prefix and the
checksum-verified Windows Node zip under .cache/wine-windows/, and falls
back to the cached zip offline. AGENTS.md ceiling 1680 -> 1695 for the
one-line command entry.
Tianyi Cui
imccyu