Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

WASI incoming HTTP handler can get stuck for JS componets when interleaving (Rust components work)

Abierto
  • ¿Algo no está bien?
#321 6 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
javascript, rust, typescript, wasm
Área
api, backend

Línea de trabajo

Reproduce el problema de la rama wasm-share-state2 con crates/wasm-runtime-axum/examples/standalone y las dos solicitudes curl, comparando los fixtures de Rust y TypeScript. Empieza en crates/wasm-runtime-host/src/lib.rs, alrededor de wasi_incoming_http_handler, y en host.rs, alrededor del manejo de consultas; después inspecciona los handlers de guest vinculados. El trabajo estará terminado cuando la segunda solicitud JS ya no se quede bloqueada y su comportamiento sea coherente con el componente de Rust.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

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:

  • JS components
  • and only if the JS component calls a host interface.

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, .... 🤷‍♀️. Out of ignorance, I filed the issue here but happy to move it elsewhere 🙏

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

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

Lenguaje dominante
C
Estrellas
293
Forks
61
Merge medio
1 d 6 h
PR fusionados (30 d)
12

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de bytecodealliance/StarlingMonkey

Todos los issues de bytecodealliance/StarlingMonkey

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.