Skip to content

smoke(8al-node): load the Pi extension with the modules the Pi host provides - #2029

Open
DeusData wants to merge 1 commit into
mainfrom
ci/smoke-8al-node-pi-host-modules
Open

smoke(8al-node): load the Pi extension with the modules the Pi host provides#2029
DeusData wants to merge 1 commit into
mainfrom
ci/smoke-8al-node-pi-host-modules

Conversation

@DeusData

@DeusData DeusData commented Sep 3, 2026

Copy link
Copy Markdown
Owner

Why

pr-smoke 8al-node imports the generated Pi extension in bare Node with an empty node_modules. That was a faithful stand-in for the Pi host only while the extension imported nothing but node: 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:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'typebox' imported from .../pi-node-probe/cbmem.mjs
FAIL 8al-node: generated Pi extension did not contain early-exit stdin errors

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:

  • a Proxy-backed typebox stub in the probe's node_modules — any Type.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 before
  • an explicit allowlist: every import … from '<specifier>' in the generated file must be a node: builtin or a package on PI_HOST_PACKAGES (currently typebox); anything else fails the probe naming the specifier. The empty node_modules used 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:

extension probe result
main@5802ccdd old OK
main@5802ccdd new OK
#1809 (b026a69) old ERR_MODULE_NOT_FOUND typebox — the CI red
#1809 (b026a69) new OK
#1809 + injected import lodash from 'lodash' new FAIL 8al-node: … packages the Pi host does not provide: lodash

Scope flags (CI change)

  • gating: unchanged (same smoke step, same venues; the C-only Linux image still SKIPs as whitelisted)
  • cost: negligible (two small files written into the existing temp probe dir)
  • flake surface: none added — no network, no install, no version resolution
  • trigger scope: unchanged

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).

…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>
@DeusData DeusData added bug Something isn't working editor/integration Editor compatibility and CLI integration priority/high Needs near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker. labels Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working editor/integration Editor compatibility and CLI integration priority/high Needs near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant