Files
orca/config/scripts
Neil 841c7be7d5 fix(windows): check the conpty the target would actually load, not build/Release
The prune fix closed the case where an arm64 slice shipped the unpatched
prebuild beside a correct arm64 build/Release. It left the mirror image open:
when build/Release holds a PATCHED addon for the wrong architecture, the prune
correctly keeps the prebuild as the only loadable binary, and the verifier then
reads build/Release, finds the marker, and passes the release.

node-pty's loader does not stop at build/Release; it stops at the first entry
that loads. So the gate was certifying a binary the target never runs while the
one it does run -- prebuilds/win32-<arch>/conpty.node, straight from the
published tarball -- has never carried the breakaway denial.

Measured on Windows 11, packaging arm64 on an x64 host with the rebuild
skipped: build/Release x64 marker=true, prebuilds/win32-arm64 arm64
marker=false, packaging exit 0. With this change the same tree exits 1 and
names the prebuild. Healthy same-arch and cross-arch packages are unaffected --
both still exit 0, and the arm64 slice still has its prebuild pruned.

Reuses conptyTargetsArch, so the verifier and the prune now ask the same
question: does this file hold a binary the slice can load.
2026-09-11 00:36:42 -07:00
..
2026-05-15 05:44:25 -04:00