web-fetch: dependency resolution fails in compiled Pi; generic unavailable error hides cause #8

New Issue

Open

opened 2026-11-02 22:45:10 +00:00 by eleith-gitea-agent · 0 comments

eleith-gitea-agent Bot commented 2026-11-02 22:45:10 +00:00

Copy link

Copy source

Summary

web_fetch from @eleith-pi/web-fetch@0.1.1 consistently returns:

Source: https://example.com
Error (unavailable): Native fetch dependencies are unavailable; check the package installation and supported platform.

The dependencies are installed and the native transport works. Investigation isolated a package-name resolution failure inside the compiled Pi runtime. An absolute-path dependency load allowed the fetch to succeed in an isolated Pi diagnostic.

The exact failing exception from the original live tool's lazy import has not been captured. The resolver failure below was captured independently inside an isolated Pi extension; it is strong evidence for the integration issue, not proof of its ultimate upstream cause.

Environment

• Linux x86_64
• Pi 1.5.0, installed as a compiled executable
• Runtime reported inside Pi: process.version = v26.3.0, process.versions.bun = 1.4.4
• Shell Node: v26.5.0
• Standalone Bun: 1.3.13 (different from Pi's embedded Bun)
• @eleith-pi/web-fetch: 0.1.1
• Dependencies: wreq-js 3.2.0, defuddle 0.19.4, linkedom 0.18.13
• Running under nono. Successful control tests ran within the same outer sandbox. This investigation did not establish a sandbox denial for the dependency load.

Installed package:

/home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch

Confirmed observations

1. Live web_fetch failed for both the PageSpeed report below and https://example.com, including format: "raw".
2. Under shell Node, imports of wreq-js, defuddle/node, and linkedom all succeeded.
3. A direct wreq-js.fetch("https://example.com", { browser: "chrome_147", os: "windows", timeout: 8000 }) returned HTTP 200 under shell Node.
4. The installed bundle's fetch core, evaluated without Pi-specific imports, fetched example.com successfully under both shell Node and standalone Bun.
5. In an isolated compiled-Pi diagnostic, the dependency's package.json was readable and an absolute import of its CJS entry succeeded, but package-name resolution failed:

const require = createRequire(
  '/home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/package.json'
);
require.resolve('wreq-js');

ResolveMessage: Cannot find module 'wreq-js'
Require stack:
- /home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/package.json

The same createRequire(...).resolve('wreq-js') succeeds under shell Node and returns:

/home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/node_modules/wreq-js/dist/wreq-js.cjs

6. In the isolated Pi diagnostic, evaluating the cached tool module with host Pi exports and a dependency-import shim reproduced unavailable when the shim used package-name resolution. Changing only the shim's wreq-js lookup to the installed absolute CJS entry produced HTTP 200 and a valid tool result. This was a diagnostic control, not a production patch.

Minimal resolver comparison

Run this inside a temporary Pi extension's session_start handler, with errors caught separately so both branches run:

import { createRequire } from 'node:module';

const require = createRequire(
  '/home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/package.json'
);

// Fails in the compiled-Pi diagnostic, succeeds in shell Node:
require.resolve('wreq-js');

// Succeeds in the compiled-Pi diagnostic:
await import(
  '/home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/node_modules/wreq-js/dist/wreq-js.cjs'
);

The isolated diagnostic was started without model requests:

pi --offline --mode rpc --no-session --no-extensions --no-mcp \
  --no-skills --no-prompt-templates --no-themes --no-context-files \
  -e /home/eleith/.local/state/nono-scratch/web-fetch-diagnostic.ts

That local scratch file contains the fuller diagnostic, including evaluation of the cached transformed bundle and the successful absolute-path control. It is a temporary local artifact, not committed source, and may be cleaned up later.

Error reporting hides the useful cause

In the installed dist/index.js:

• Around line 394: lazy import("wreq-js") catches and discards the original exception.
• Around lines 1853–1859: fetchTool broadly catches unexpected failures and reports unavailable.
• Around lines 1911–1921: boundedItem replaces error messages with messages[item.code], hiding even more specific internal messages.

Consequently, the visible tool error cannot distinguish a missing native binding, package-resolution failure, or another unexpected exception.

Suggested investigation / fixes

• Capture the original lazy-import exception through a bounded, sanitized diagnostic channel; preserve useful error codes/causes without exposing credentials.
• Reproduce using the compiled Pi executable, not only Node tests or a different standalone Bun version.
• Investigate the interaction between Pi's extension/Jiti loading, embedded Bun resolution, and wreq-js package exports (bun/require point to CJS; import points to ESM).
• Evaluate static dependency imports or bundling the JS wrapper while leaving native bindings external. These are candidates to test, not verified fixes.
• Add a compiled-Pi smoke test for an actual raw fetch, then separately verify markdown extraction and batch fetching.
• Avoid hardcoding the local absolute path as a production fix.

No installed plugin files were modified during this investigation. Only a scratch diagnostic extension was created.

Original context

Discovered while investigating:
https://pagespeed.web.dev/analysis/https-when-eleith-com-schedule-walk/9tc5ob8nsx?form_factor=mobile

curl could retrieve that report; example.com reproduced the tool failure independently of PageSpeed.

## Summary `web_fetch` from `@eleith-pi/web-fetch@0.1.1` consistently returns: ```text Source: https://example.com Error (unavailable): Native fetch dependencies are unavailable; check the package installation and supported platform. ``` The dependencies are installed and the native transport works. Investigation isolated a package-name resolution failure inside the compiled Pi runtime. An absolute-path dependency load allowed the fetch to succeed in an isolated Pi diagnostic. The exact failing exception from the original live tool's lazy import has **not** been captured. The resolver failure below was captured independently inside an isolated Pi extension; it is strong evidence for the integration issue, not proof of its ultimate upstream cause. ## Environment - Linux x86_64 - Pi 1.5.0, installed as a compiled executable - Runtime reported **inside Pi**: `process.version = v26.3.0`, `process.versions.bun = 1.4.4` - Shell Node: v26.5.0 - Standalone Bun: 1.3.13 (different from Pi's embedded Bun) - `@eleith-pi/web-fetch`: 0.1.1 - Dependencies: `wreq-js` 3.2.0, `defuddle` 0.19.4, `linkedom` 0.18.13 - Running under nono. Successful control tests ran within the same outer sandbox. This investigation did not establish a sandbox denial for the dependency load. Installed package: ```text /home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch ``` ## Confirmed observations 1. Live `web_fetch` failed for both the PageSpeed report below and `https://example.com`, including `format: "raw"`. 2. Under shell Node, imports of `wreq-js`, `defuddle/node`, and `linkedom` all succeeded. 3. A direct `wreq-js.fetch("https://example.com", { browser: "chrome_147", os: "windows", timeout: 8000 })` returned HTTP 200 under shell Node. 4. The installed bundle's fetch core, evaluated without Pi-specific imports, fetched `example.com` successfully under both shell Node and standalone Bun. 5. In an isolated compiled-Pi diagnostic, the dependency's `package.json` was readable and an absolute import of its CJS entry succeeded, but package-name resolution failed: ```js const require = createRequire( '/home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/package.json' ); require.resolve('wreq-js'); ``` ```text ResolveMessage: Cannot find module 'wreq-js' Require stack: - /home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/package.json ``` The same `createRequire(...).resolve('wreq-js')` succeeds under shell Node and returns: ```text /home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/node_modules/wreq-js/dist/wreq-js.cjs ``` 6. In the isolated Pi diagnostic, evaluating the cached tool module with host Pi exports and a dependency-import shim reproduced `unavailable` when the shim used package-name resolution. Changing **only the shim's `wreq-js` lookup** to the installed absolute CJS entry produced HTTP 200 and a valid tool result. This was a diagnostic control, not a production patch. ## Minimal resolver comparison Run this inside a temporary Pi extension's `session_start` handler, with errors caught separately so both branches run: ```ts import { createRequire } from 'node:module'; const require = createRequire( '/home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/package.json' ); // Fails in the compiled-Pi diagnostic, succeeds in shell Node: require.resolve('wreq-js'); // Succeeds in the compiled-Pi diagnostic: await import( '/home/eleith/.pi/agent/npm/node_modules/@eleith-pi/web-fetch/node_modules/wreq-js/dist/wreq-js.cjs' ); ``` The isolated diagnostic was started without model requests: ```sh pi --offline --mode rpc --no-session --no-extensions --no-mcp \ --no-skills --no-prompt-templates --no-themes --no-context-files \ -e /home/eleith/.local/state/nono-scratch/web-fetch-diagnostic.ts ``` That local scratch file contains the fuller diagnostic, including evaluation of the cached transformed bundle and the successful absolute-path control. It is a temporary local artifact, not committed source, and may be cleaned up later. ## Error reporting hides the useful cause In the installed `dist/index.js`: - Around line 394: lazy `import("wreq-js")` catches and discards the original exception. - Around lines 1853–1859: `fetchTool` broadly catches unexpected failures and reports `unavailable`. - Around lines 1911–1921: `boundedItem` replaces error messages with `messages[item.code]`, hiding even more specific internal messages. Consequently, the visible tool error cannot distinguish a missing native binding, package-resolution failure, or another unexpected exception. ## Suggested investigation / fixes - Capture the original lazy-import exception through a bounded, sanitized diagnostic channel; preserve useful error codes/causes without exposing credentials. - Reproduce using the **compiled Pi executable**, not only Node tests or a different standalone Bun version. - Investigate the interaction between Pi's extension/Jiti loading, embedded Bun resolution, and `wreq-js` package exports (`bun`/`require` point to CJS; `import` points to ESM). - Evaluate static dependency imports or bundling the JS wrapper while leaving native bindings external. These are candidates to test, **not verified fixes**. - Add a compiled-Pi smoke test for an actual raw fetch, then separately verify markdown extraction and batch fetching. - Avoid hardcoding the local absolute path as a production fix. No installed plugin files were modified during this investigation. Only a scratch diagnostic extension was created. ## Original context Discovered while investigating: https://pagespeed.web.dev/analysis/https-when-eleith-com-schedule-walk/9tc5ob8nsx?form_factor=mobile `curl` could retrieve that report; `example.com` reproduced the tool failure independently of PageSpeed.

eleith-gitea-agent Bot referenced this issue 2026-11-03 00:03:00 +00:00

docs(web-fetch): note standalone Pi dependency resolution issue #9

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

@eleith-pi/web-search-codex@0.1.3

@eleith-pi/web-fetch@0.1.2

@eleith-pi/tool-rendering@0.1.6

@eleith-pi/codex@0.2.3

@eleith-pi/codex@0.2.2

@eleith-pi/codex@0.2.1

@eleith-pi/codex@0.2.0

@eleith-pi/tool-rendering@0.1.5

@eleith-pi/context-codex@0.1.1

@eleith-pi/web-fetch@0.1.1

@eleith-pi/web-fetch@0.1.0

@eleith-pi/context-codex@0.1.0

@eleith-pi/web-search-codex@0.1.2

@eleith-pi/tool-rendering@0.1.4

@eleith-pi/web-search-codex@0.1.1

@eleith-pi/web-search-codex@0.1.0

@eleith-pi/notifications@0.1.2

@eleith-pi/context-window@0.1.2

@eleith-pi/tool-rendering@0.1.3

@eleith-pi/title-status@0.1.3

@eleith-pi/compact-editor-chrome@0.1.2

@eleith-pi/tool-rendering@0.1.2

@eleith-pi/tool-rendering@0.1.1

@eleith-pi/welcome@0.1.1

@eleith-pi/compact-editor-chrome@0.1.1

@eleith-pi/context-window@0.1.1

@eleith-pi/notifications@0.1.1

@eleith-pi/progress@0.1.1

@eleith-pi/title-status@0.1.2

@eleith-pi/tool-rendering@0.1.0

@eleith-pi/welcome@0.1.0

@eleith-pi/compact-editor-chrome@0.1.0

@eleith-pi/context-window@0.1.0

@eleith-pi/notifications@0.1.0

@eleith-pi/progress@0.1.0

@eleith-pi/title-status@0.1.1

@eleith/pi-extension-tool-rendering@0.1.0

@eleith/pi-extension-welcome@0.1.0

@eleith/pi-extension-compact-editor-chrome@0.1.0

@eleith/pi-extension-context-window@0.1.0

@eleith/pi-extension-notifications@0.1.0

@eleith/pi-extension-progress@0.1.0

@eleith/pi-extension-title-status@0.1.0

Labels

Clear labels

bug

Something is not working

duplicate

This issue or pull request already exists

enhancement

New feature

help wanted

Need some help

invalid

Something is wrong

question

More information is needed

wontfix

This won't be fixed

No labels

Milestone

No items

No Milestone

Assignees

Clear assignees

eleith-gitea-agent Bot eleith (eleith)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: eleith/pi-extensions#8