Stream: git-wasmtime

Topic: wasmtime / issue #13814 WASI incoming HTTP handler can ge...

view this post on Zulip Wasmtime GitHub notifications bot (Jul 03 2026 at 12:58):

ignatz opened issue #13814:

For a long time, I wanted to change the execution model of my wasmtime runtimes from being ephemeral and short-lived to being long-lived, i.e. reusing a store to interleave multiple HTTP requests (instead of constructing and destroying requests per state).

I actually had it rolled out at some point to then roll back because it worked for rust components but not for:

To be clear, besides having a shallow understanding of where it locks up, I don't understand what the issue is, e.g. it could be an issue with my host implementations (though it works for rust), it could be an issue with jco or seamonkey's js event loop, wasmtime itself, .... :woman_shrugging:. Out of ignorance, I filed the issue here but happy to move it elsewhere :folded_hands:

Test Case

git clone https://github.com/trailbaseio/trailbase.git
cd trailbase
git checkout wasm-share-state2
cd crates/wasm-runtime-axum

# Running with the "working" Rust component
cargo run --example standalone -- --path=../../client/testfixture/wasm/wasm_guest_testfixture.wasm
# Will produce an error but the second run of curl won't block up the system.
curl "localhost:3000/addDeletePost"
curl "localhost:3000/addDeletePost"

# Running with the "broken" JS component
cargo run --example standalone -- --path=../../client/testfixture/wasm/wasm_ts_guest_testfixture.wasm
curl "localhost:3000/addDeletePost"
curl "localhost:3000/addDeletePost"

Note, the above is running pre-built, checked-in WASM components. Their respective HTTP handler implementations live here:

When running curl the second time for the JS component, it's this call to wasi_incoming_http_handler: https://github.com/trailbaseio/trailbase/blob/57e912f042e44f313139f99f59bd54ec968fba3b/crates/wasm-runtime-host/src/lib.rs#L354 that gets stuck.

A potential culprit is how I hacked the async host function, I.e. the component-side query() sends and outgoing http-request that is intercepted and handled here: https://github.com/trailbaseio/trailbase/blob/57e912f042e44f313139f99f59bd54ec968fba3b/crates/wasm-runtime-host/src/host.rs#L126-L130

(The latter is one of the reasons why I've sat this out so long, I was hoping that WASIp3 may fix my issue, but it seems I keep running into obstacles :smiling_face_with_tear: )

Expected Results

Ideally I would expect the JS component to behave like the Rust component. However, them behaving more consistently would already be an improvement.

Actual Results

Execution gets stuck.

Versions and Environment

Wasmtime version or commit: v46
Operating system: debian
Architecture: amd64

view this post on Zulip Wasmtime GitHub notifications bot (Jul 03 2026 at 12:58):

ignatz added the bug label to Issue #13814.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 03 2026 at 15:15):

tschneidereit commented on issue #13814:

@ignatz you're most likely running into issues with the JS runtime (StarlingMonkey), which isn't set up to handle reuse of instances. See this and the following messages. I'm working in a replacement for that runtime which will support WASIp3 and full reuse, including handling multiple requests concurrently, not just serially. With P3, that is in general something we've switched to as the execution model, so hopefully your changes should mostly be absorbed by that

view this post on Zulip Wasmtime GitHub notifications bot (Jul 03 2026 at 15:31):

ignatz commented on issue #13814:

Thanks for the quick reply. That sounds certainly very related. I haven't really tested true concurrency yet and will now keep my fingers off it. Can your hypothesis explain why subsequent requests block up in the presence of host calls eventhough the handler completes on first invocation. Feels like there may be something lingering :woman_shrugging:

view this post on Zulip Wasmtime GitHub notifications bot (Jul 03 2026 at 15:38):

tschneidereit commented on issue #13814:

Can your hypothesis explain why subsequent requests block up in the presence of host calls eventhough the handler completes on first invocation. Feels like there may be something lingering :woman_shrugging:

Yes: StarlingMonkey doesn't properly clean up after a request is done, so the next request hits weird inconsistent state. In debug builds that manifests as a failing assert, but I don't remember what the symptoms are in release builds.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 03 2026 at 15:41):

ignatz commented on issue #13814:

That would explain it. Thanks so much and thanks for being on top. I'll have to wait then. Is there an ETA? Can I help out as a canary?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 03 2026 at 16:01):

tschneidereit commented on issue #13814:

I unfortunately don't have a good ETA, sorry :( There's too much development work with wide error-margins on estimates still to be done for that. It's my highest priority though, and others are starting to chip in, so "this Summer" is realistic, I think.

As for helping out, while I just mentioned that others are chipping in, I think it's too early to open that up more broadly. I'll share updates in the Zulip thread I linked to, though, so that's a good way to follow along

view this post on Zulip Wasmtime GitHub notifications bot (Jul 06 2026 at 02:59):

alexcrichton commented on issue #13814:

@tschneidereit are you able to transfer this issue to StarlingMonkey?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 06 2026 at 09:13):

tschneidereit transferred issue #13814 WASI incoming HTTP handler can get stuck for JS componets when interleaving (Rust components work) to bytecodealliance/StarlingMonkey/#321.

Last updated: Jul 29 2026 at 05:03 UTC