Stream: git-wasmtime

Topic: wasmtime / issue #10784 Allow wasi-http to return error t...

Wasmtime GitHub notifications bot (May 16 2025 at 04:33):

xofyarg opened issue #10784:

Feature

Giving the following wasi-http design and implementation:

resource response-outparam {
   set: static func(
     param: response-outparam,
     response: result<outgoing-response, error-code>,
   );
}

fn set(
    &mut self,
    id: Resource<HostResponseOutparam>,
    resp: Result<Resource<HostOutgoingResponse>, types::ErrorCode>,
) -> wasmtime::Result<()> {
    let val = match resp {
        Ok(resp) => Ok(self.table().delete(resp)?.try_into()?),
        Err(e) => Err(e),
    };

    self.table()
        .delete(id)?
        .result
        .send(val)  <--- may fail the host call
        .map_err(|_| anyhow::anyhow!("failed to initialize response"))
}

The common scenario is a host is waiting for a response from the guest under a given timeout. If the timeout is reached without having anything from the guest, the host will drop the receiver side of the channel, which will fail the hostcall and likely crash the wasi program.

Benefit

The error doesn't seem to be fatal, and the caller should be able to decide what to do next.

Implementation

Maybe allow the set API to return an error to the caller.

Wasmtime GitHub notifications bot (May 18 2025 at 09:34):

alexcrichton commented on issue #10784:

Can you describe your situation in a bit more detail? For example to confirm, you want to set a timeout for the guest to generate a response, but you do not want to set a timeout (or you perhaps want a different timeout?) for the guest's execution itself?

Wasmtime GitHub notifications bot (May 18 2025 at 09:34):

alexcrichton added the wasi:api label to Issue #10784.

Wasmtime GitHub notifications bot (May 18 2025 at 20:19):

xofyarg commented on issue #10784:

Sure. The host provides an async request stream to the guest, where each item contains incoming-request and response-outparam. After sending the request to the guest, the host then wait for the receiver side of the channel, which put its sender in WasiHttpView::new_response_outparam. The waiting task above is wrapped by a timeout, that's currently the only timeout. The guest execution itself doesn't have any timeout, partly because it's a bit out of our control. As the guest has an async runtime, we bridge a request processing task from the host to one from the guest via channel. The expectation is when the host timeout is reached, the host task will be dropped, and on the guest side, depends on the implementation, either the timeout is longer than the host side, or no timeout at all, it should fail the guest request processing task itself, but not the whole guest program.

wit:

resource req-stream {
  subscribe: func() -> pollable;
  next: func() -> option<tuple<incoming-request, response-outparam>>;
}

host:

let (tx, rx) = oneshot::channel();
stream.send((hyper_req, tx)).await;
tokio::time::timeout(duration, rx).await;

guest:

async fn process_request() {
    ...
    if let Some((incoming_req, outparam)) = async_stream.next().await {
        ResponseOutparam::set(outparam, f(incoming_req).await);
    }
    ...
}

Wasmtime GitHub notifications bot (May 18 2025 at 21:15):

alexcrichton commented on issue #10784:

That makes sense yeah, thanks for explaining. I was curious as well for the rationale for why it's architected like this (as opposed to timing out the guest, which you probably want to do no matter what), but that's also not necessarily the most important part here.

To clarify though the change you're asking for here is one for the wasi-http repository. Wasmtime won't change the WITs from upstream in one-off cases like this. That means that changing the actual WIT API is not a change that's in-scope for this repository.

One possibility though, without changing WITs, would be to remove this trap from Wasmtime's implementation. One could argue that even if the response is sent successfully there's no guarantee it was actually picked up by the host. Along that line of logic it seems not unreasonable to me that we could simply drop the error here and intentionally ignore it, avoiding trapping the guest. Forwarding this information to the guest (aka "this response will never be sent") can be an issue for the uptime wasi-http repository.

Would you be interested in seeing if other folks would agree with this change? Perhaps with a PR sketching this out, a test, and maybe an issue upstream as well for changing the interface?

Wasmtime GitHub notifications bot (May 25 2025 at 06:36):

xofyarg commented on issue #10784:

Raised a PR. Upstream wasi-http interface changed in 0.3.0 draft, giving us opportunity to return an error.

Wasmtime GitHub notifications bot (Jun 02 2025 at 22:48):

pchickey closed issue #10784:

Feature

Giving the following wasi-http design and implementation:

resource response-outparam {
   set: static func(
     param: response-outparam,
     response: result<outgoing-response, error-code>,
   );
}

fn set(
    &mut self,
    id: Resource<HostResponseOutparam>,
    resp: Result<Resource<HostOutgoingResponse>, types::ErrorCode>,
) -> wasmtime::Result<()> {
    let val = match resp {
        Ok(resp) => Ok(self.table().delete(resp)?.try_into()?),
        Err(e) => Err(e),
    };

    self.table()
        .delete(id)?
        .result
        .send(val)  <--- may fail the host call
        .map_err(|_| anyhow::anyhow!("failed to initialize response"))
}

The common scenario is a host is waiting for a response from the guest under a given timeout. If the timeout is reached without having anything from the guest, the host will drop the receiver side of the channel, which will fail the hostcall and likely crash the wasi program.

Benefit

The error doesn't seem to be fatal, and the caller should be able to decide what to do next.

Implementation

Maybe allow the set API to return an error to the caller.

Wasmtime GitHub notifications bot (Jun 02 2025 at 22:48):

pchickey commented on issue #10784:

Thanks for raising this issue and fixing it! I believe this has been closed by https://github.com/bytecodealliance/wasmtime/pull/10833, please re-open if I misunderstood.

Last updated: Dec 06 2025 at 07:03 UTC