smoke(8al-node): load the Pi extension with the modules the Pi host provides - #2029
Open
DeusData wants to merge 1 commit into
Open
smoke(8al-node): load the Pi extension with the modules the Pi host provides#2029DeusData wants to merge 1 commit into
DeusData wants to merge 1 commit into
Conversation
…rovides The 8al-node probe imports the generated Pi extension in bare Node with an empty node_modules. That was a sound stand-in for the Pi host only while the extension imported nothing but node: builtins; the first package import (`typebox`, Pi's schema library for tool parameters — a real Pi dependency, verified against pi-coding-agent 0.84.4 on #1809) can never resolve there, so the probe fails on a correct extension and would pass a wrong one just as readily. Give the probe what the host gives the extension: a Proxy-backed `typebox` stub in the probe's node_modules (any Type.X(...) returns a descriptor, so the probe never tracks which helpers the emitter uses — it only exercises the tool lifecycle), plus an explicit allowlist: every import specifier in the generated file must be a node: builtin or a package on PI_HOST_PACKAGES, otherwise the probe fails naming the specifier. That turns the guarantee the empty node_modules gave by accident (no surprise dependency) into an asserted contract. Verified locally by running only the 8al-node block against extensions generated by two binaries: main@5802ccdd extension, old probe: OK; new probe: OK #1809 extension, old probe: ERR_MODULE_NOT_FOUND typebox (the CI red) #1809 extension, new probe: OK #1809 extension + an injected 'lodash' import, new probe: FAIL 8al-node: ... packages the Pi host does not provide: lodash Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
pr-smoke8al-node imports the generated Pi extension in bare Node with an emptynode_modules. That was a faithful stand-in for the Pi host only while the extension imported nothing butnode:builtins. #1809 adds the first package import —typebox, Pi's schema library for tool parameters, a real Pi dependency (verified against pi-coding-agent 0.84.4 by its author) — and the probe can never resolve it:So the probe rejects a correct extension, and the failure message blames the wrong thing.
What
Give the probe what the host gives the extension:
typeboxstub in the probe'snode_modules— anyType.X(...)returns a descriptor, so the probe never has to track which helpers the emitter uses; it only exercises the tool lifecycle (EPIPE handling, JSON authority), exactly as beforeimport … from '<specifier>'in the generated file must be anode:builtin or a package onPI_HOST_PACKAGES(currentlytypebox); anything else fails the probe naming the specifier. The emptynode_modulesused to give that "no surprise dependency" guarantee by accident; now it is an asserted contract with a readable failure.Main's extension (only
node:child_process) is unaffected.Verified
Ran only the 8al-node block against extensions generated by two binaries:
ERR_MODULE_NOT_FOUND typebox— the CI redimport lodash from 'lodash'FAIL 8al-node: … packages the Pi host does not provide: lodashScope flags (CI change)
Unblocks the maintainer-side half of #1809 (its remaining red,
test_agent_clients.c:1181, is the PR's own and has been handed to the author).