Using `fetch` traps

[kyleconroy]

Using the command-extended world, I'm trying to use fetch. The following code compiles to WASM but traps at runtime.

// All of the same imports and exports available in the wasi:cli/command world
// with addition of HTTP proxy related imports:
world command-extended {
  include wasi:cli/[email protected];
  import wasi:http/[email protected];
}

// app.js
export const run = {
    async run() {
        const resp = await fetch("http://example.com");
        console.log(`status: ${resp.status}`)
        console.log('Hello, world!');
    }
}

import { componentize } from '@bytecodealliance/componentize-js';
import { readFile, writeFile } from 'node:fs/promises';
import { resolve } from 'node:path';

const jsSource = await readFile("app.js", 'utf8');

const { component } = await componentize(jsSource, {
  witPath: resolve("../../wit"),
  worldName: "command-extended",
  enableFeatures: ['http'],
});

await writeFile('cli.wasm', component);

% wasmtime run -Shttp cli.wasm
Error: failed to run main module `cli.wasm`

Caused by:
    0: failed to invoke `run` function
    1: error while executing at wasm backtrace:
           0: 0x2978c5 - <unknown>!<wasm function 332>
           1: 0x3d4992 - <unknown>!<wasm function 810>
           2: 0x33649f - <unknown>!<wasm function 523>
           3: 0xc7b6b - <unknown>!<wasm function 112>
           4: 0x333c63 - <unknown>!<wasm function 519>
           5: 0x3362fa - <unknown>!<wasm function 523>
           6: 0x67f172 - <unknown>!<wasm function 4654>
           7: 0x4de98a - <unknown>!<wasm function 1628>
           8: 0x3c1a15 - <unknown>!<wasm function 769>
           9: 0x7749be - <unknown>!wasi:cli/[email protected]#run
    2: wasm trap: wasm `unreachable` instruction executed

Environment

I'm using ComponentizeJS 0.8.3 and wasmtime 19.

% wasmtime --version
wasmtime-cli 19.0.0 (6e0abd754 2024-03-20)

[guybedford]

Thanks for sharing - yes right now fetch is disabled in ComponentizeJS. The reason for this is when I enabled it I get an issue in StarlingMonkey, which is tracking here - https://github.com/fermyon/StarlingMonkey/issues/19.

Once this is fixed upstream we should be able to enable it in ComponentizeJS.

[guybedford]

Note that in the mean time it is possible to import and use OutgoingRequest directly.

[radu-matei]

@guybedford -- do you have a pointer in ComponentizeJS where you're disabling fetch? I plan on testing with new versions of the StarlingMonkey embedding and would like to use the new version from ComponentizeJS.

Thanks.

[guybedford]

@radu-matei I believe you just need to add enableFeatures: ['http'] to the componentize options for it to reenable it per https://github.com/bytecodealliance/ComponentizeJS/blob/main/src/componentize.js#L83.

[radu-matei]

Thanks, @guybedford! I'll try this out once the fetch work is in a testable state and report back.

[jdegoes]

We have a fix for some issues with fetch here, if anyone needs it urgently:

https://github.com/bytecodealliance/StarlingMonkey/pull/49

[damianofalcioni]

Hi, I tried this fetch sample using ComponentizeJS 0.10.5 and wasmtime 24.0.0. No compilation errors and running errors, but it print nothing on the console. Every console.log after the await fetch is not visualized. Any suggestion?

[guybedford]

@damianofalcioni try adding enableFeatures: ['http'] to the componentize config.

[damianofalcioni]

Hi, yes it has already the enableFeatures: ['http'] as in the code on top of this thread (is exactly the same). Same behavior occur also in node.js, after JCO transpile.

[guybedford]

Fixed in https://github.com/bytecodealliance/ComponentizeJS/pull/131.

[kyleconroy]

Went ahead and tried out the new version and it worked perfectly. Thank you so much!