Stream: git-wasmtime

Topic: wasmtime / PR #13345 wasi-http: treat I32Exit(0) as grace...

Wasmtime GitHub notifications bot (May 12 2026 at 23:13):

posborne opened PR #13345 from posborne:wasi-http-cli-exit-0-not-error to bytecodealliance:main:

When a guest calls wasi:cli/exit(ok) from within a wasi:http/handler instance, the host exit implementation returns Err(I32Exit(0)). This propagated as a worker error, causing wasmtime serve to log a spurious "worker error" message and wasm backtrace on what is actually a clean, guest-controlled shutdown.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (May 12 2026 at 23:13):

posborne requested pchickey for a review on PR #13345.

Wasmtime GitHub notifications bot (May 12 2026 at 23:13):

posborne requested wasmtime-wasi-reviewers for a review on PR #13345.

Wasmtime GitHub notifications bot (May 13 2026 at 14:44):

alexcrichton commented on PR #13345:

Thanks! Could a test be added for this as well? For example crates/test-programs/src/bin/p3_cli_serve_hello_world.rs and related similar programs are how we're currently testing wasmtime serve

Wasmtime GitHub notifications bot (May 13 2026 at 17:30):

posborne commented on PR #13345:

Thanks! Could a test be added for this as well? For example crates/test-programs/src/bin/p3_cli_serve_hello_world.rs and related similar programs are how we're currently testing wasmtime serve

Yeah, I'll add a test for this general case (one request per session) -- the change here just removes error logging in the non-error case but coverage would be useful even if it isn't asserting on log non-existence.

Wasmtime GitHub notifications bot (May 13 2026 at 23:07):

posborne requested wasmtime-core-reviewers for a review on PR #13345.

Wasmtime GitHub notifications bot (May 13 2026 at 23:07):

posborne updated PR #13345.

Wasmtime GitHub notifications bot (May 13 2026 at 23:08):

posborne commented on PR #13345:

@alexcrichton In doing these tests, I think I found a related bug that breaks use of the future returned by response.new intended to indicate when trasmission of the response is complete.

Currently, in wasmtime, it is possible for this to indicate completion before the bytes have been handed off to hyper. If the guest keys off this to exit, then bytes are dropped on the floor. Here I have pushed 3 additional commits:

1. A basic test showing/covering how to use wasi-http with single-request-per-instance via backpressure and cli:exit. This test only fails spuriously due to the race on the response actually being handed off prior to repsonse future resolution.
2. A test case that consistently reproduces the spurious failure from 1.
3. A patch to the serve implementation that changes the behavior to make these tests pass.

The final patch in the series (dfe334964444c41dd194c9d7703526e4c1a2bcbf) I'm not entirely particularly confident in as I don't feel I have a confident grasp on the various futures going on and where/how errors in this chain might be involved.

@tschneidereit It sounds like you've also been doing some work with cli:exit and wasi-http -- do the test cases here make sense and have you seen similar results? Is the approach taken in my tests a valid use of the future provided by response.new?

Last updated: Jun 01 2026 at 09:49 UTC