mirror of
https://github.com/stablyai/orca.git
synced 2026-09-30 00:03:15 +00:00
Merge Sim
1b45d648e4
CI caught the real defect: the win32 guard test read
isWindowsProcessStartTimeAvailable() as true and then found 0 rows
carrying creationTimeMs. Unlike node-pty, this package publishes a
prebuilt .node at the same build/Release path node-gyp writes to, so
pnpm patches the source tree and leaves that binary alone. A host then
holds a patched lib/index.js -- ProcessDataFlag.CreationTime and all --
over a binary that ignores flag 4, and neither a load check nor a path
check can see the difference.
So the binary now says so itself: addon.cc exports
supportedProcessDataFlags, lib/index.js re-exports it, and
- windows-process-tree-creation-time.cjs asserts it during install,
which is what forces a from-source rebuild. It is shared by the Node
probe in ensure-native-runtime.mjs and the Electron probe in
rebuild-native-deps.mjs, exactly as node-pty-job-ownership.cjs is --
the Electron half matters because that probe decides onlyModules, so
without it the packaged app would ship the stale prebuilt.
- isWindowsProcessStartTimeAvailable() gates on the reported bit, not
the enum. Believing the enum is worse than reporting false: the
descendant snapshot returns null forever and the exit proof latches
unverifiable while structured chat believes it has a reaper.
rebuildNodeRuntimeModules could not actually have rebuilt this package:
the patched binding.gyp includes deps/node-addon-api, which the tarball
does not ship, and node-gyp must run from the physical dir.
Also closes the relay repair path's divergence: repairCreationTimeSources
wrote the C++ but not the buildNode splat or the tree-node typing, and
assertPatchApplied checked neither, so a repaired tree passed as patched
with buildProcessTree silently dropping the field.
The guard test is unchanged.
43 lines
1.7 KiB
JavaScript
43 lines
1.7 KiB
JavaScript
'use strict'
|
|
|
|
/**
|
|
* Prove the COMPILED addon understands `CREATIONTIME`, not just the patched JS.
|
|
*
|
|
* Unlike node-pty, this package ships a prebuilt `.node` at the same
|
|
* `build/Release/` path node-gyp writes to, so neither a load nor a path check
|
|
* can tell a stale prebuilt from a source build. pnpm patches the source tree
|
|
* and leaves that prebuilt in place, which is how `ProcessDataFlag.CreationTime`
|
|
* came to exist in `lib/index.js` on a binary that ignores flag 4 -- the gate
|
|
* read true and every row came back without `creationTimeMs`.
|
|
*
|
|
* `supportedProcessDataFlags` is exported by the patched `addon.cc`, so its
|
|
* presence is the binary's own answer. Shared by the Node and Electron probes
|
|
* the way `node-pty-job-ownership.cjs` is.
|
|
*/
|
|
|
|
/** `ProcessDataFlags::CREATIONTIME` in src/process.h. */
|
|
const CREATION_TIME_FLAG = 4
|
|
|
|
function assertWindowsProcessTreeCreationTime({ module, platform = process.platform }) {
|
|
if (platform !== 'win32') {
|
|
return
|
|
}
|
|
const supported = module?.supportedProcessDataFlags
|
|
if (typeof supported === 'number' && (supported & CREATION_TIME_FLAG) !== 0) {
|
|
return
|
|
}
|
|
throw new Error(
|
|
[
|
|
'@vscode/windows-process-tree does not report CreationTime support',
|
|
`(supportedProcessDataFlags=${String(supported)}).`,
|
|
'That is the tarball prebuilt, not a build of the patched source, so every',
|
|
'process row comes back without creationTimeMs: Windows descendant exit',
|
|
'verification cannot identify a PID and structured Claude/Codex chat runs',
|
|
'with an unprovable child-tree reaper.',
|
|
'Rebuild it from source so config/patches/@vscode__windows-process-tree@0.8.0.patch applies.'
|
|
].join(' ')
|
|
)
|
|
}
|
|
|
|
module.exports = { assertWindowsProcessTreeCreationTime, CREATION_TIME_FLAG }
|