Stream: git-wasmtime

Topic: wasmtime / PR #13404 refactor `wasmtime_wasi_http::handler`

Wasmtime GitHub notifications bot (May 18 2026 at 18:13):

dicej requested alexcrichton for a review on PR #13404.

Wasmtime GitHub notifications bot (May 18 2026 at 18:13):

dicej requested wasmtime-wasi-reviewers for a review on PR #13404.

Wasmtime GitHub notifications bot (May 18 2026 at 18:13):

dicej opened PR #13404 from dicej:wasmtime-wasi-http-handler-refactor to bytecodealliance:main:

The goal here is to make this module more flexible and easier to reuse.

The heart of the changes is an overhaul of the HandlerState trait. Previously, it mostly consisted of functions returning Duration or usize representing various timeouts and reuse limits. The drawback to that API is that it prevented the embedder from dynamically adjusting timeouts and limits based on service load and resource usage. The new API uses pollable traits to provide such dynamism, allowing the embedder to e.g. expire and reclaim idle instances early if a pooling allocator limit has been reached.

Other high-level changes:

• ProxyHandler::spawn has been replaced with ProxyHandler::handle, which takes a http::Request and returns a Result<http::Response, wasmtime::Error>, saving the embedder from needing to manage task spawning, type conversions, channels, etc.

• ProxyHandler::handle may return a wasmtime::Error which may be downcast to an InstantiationError, which itself may contain a PoolConcurrencyLimitError representing a pooling allocator limit being reached. In this case, the embedder may wish to expire and reclaim instances more aggressively and arrange to retry the handle call(s) as instances are reclaimed.

• Implementing HandlerState now requires providing an InstanceExpiration implementation as well. An instance of this type will be created for each worker and polled as part of the worker future to determine when the worker and its associated instance should be expired.

• HandlerState::drop is called when the worker exits (normally or with a failure), giving the embedder the chance to interrogate the store used by that worker (for e.g. telemetry) prior to dropping it.

• I've added a new p2::types::WasiHttpCtxView::new_response_outparam_from_callback function as a more flexible alternative to the existing new_response_outparam for cases where you don't have a tokio::sync::oneshot::Sender handy.

<!--
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 18 2026 at 18:13):

dicej requested wasmtime-core-reviewers for a review on PR #13404.

Wasmtime GitHub notifications bot (May 18 2026 at 18:13):

dicej requested wasmtime-default-reviewers for a review on PR #13404.

Wasmtime GitHub notifications bot (May 18 2026 at 18:24):

dicej updated PR #13404.

Wasmtime GitHub notifications bot (May 18 2026 at 20:32):

dicej updated PR #13404.

Wasmtime GitHub notifications bot (May 18 2026 at 22:27):

:memo: pchickey submitted PR review.

Wasmtime GitHub notifications bot (May 18 2026 at 22:27):

:speech_balloon: pchickey created PR review comment:

There needs to be some way to determine which of the running instances (though, ideally, also the request where possible, though that now requires guest support...) a print line came from - is this just not done yet in the current design?

Wasmtime GitHub notifications bot (May 18 2026 at 23:24):

dicej updated PR #13404.

Wasmtime GitHub notifications bot (May 18 2026 at 23:47):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (May 18 2026 at 23:47):

:speech_balloon: dicej created PR review comment:

Given the possibility of concurrent execution in WASIp3, this can't be done in general; i.e. we can't unambiguously determine which request generated which stdio activity.

Previously, I had written "best effort" code to plumb the request ID through in the case where instance reuse is disabled. I removed it in this PR because it seemed like more trouble than it was worth given that the vision going forward is to reuse instances by default. I can restore it, though, if desired.

Wasmtime GitHub notifications bot (May 18 2026 at 23:48):

:speech_balloon: dicej edited PR review comment.

Wasmtime GitHub notifications bot (May 18 2026 at 23:49):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (May 18 2026 at 23:49):

:speech_balloon: dicej created PR review comment:

If we only need to distinguish instance IDs and not request IDs, then yes, we can do that without ambiguity.

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

:memo: pchickey submitted PR review.

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

:speech_balloon: pchickey created PR review comment:

If I understand correctly, this host code is going to still execute p2 guests where instances are not reused, so we should retain the way to tag those instances in the print, otherwise it degrades the experience for existing users of p2.

I agree we need to do plumbing elsewhere to get a nice user experience in all cases with p3, but with backpressure on instance reuse there is still the possibility of many instances in p3 as well, so we will still need a way to disambiguate even if each instance keeps their own internal counter of request. (And it shows theres probably a need for some mechanism to get a unique id for a wasi-http request without depending on it being injected into a header, but thats a totally different problem for now...)

Wasmtime GitHub notifications bot (May 19 2026 at 17:31):

:speech_balloon: pchickey edited PR review comment.

Wasmtime GitHub notifications bot (May 19 2026 at 18:32):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (May 19 2026 at 18:32):

:speech_balloon: dicej created PR review comment:

OK, so if I (re-)add the ability to tag stdio output on a per-instance basis (without trying to do it on a per-request basis), will that be sufficient, at least for the time being?

Wasmtime GitHub notifications bot (May 19 2026 at 19:39):

dicej updated PR #13404.

Wasmtime GitHub notifications bot (May 19 2026 at 19:39):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (May 19 2026 at 19:39):

:speech_balloon: dicej created PR review comment:

I just pushed an update; let me know what you think.

Wasmtime GitHub notifications bot (May 20 2026 at 16:24):

:memo: pchickey submitted PR review.

Wasmtime GitHub notifications bot (May 20 2026 at 16:24):

:speech_balloon: pchickey created PR review comment:

Thanks! Thats a good spot for this to be presently, and I will pursue the spec changes that I think are required to fix the rest separately.

Wasmtime GitHub notifications bot (May 20 2026 at 22:15):

:memo: tschneidereit submitted PR review.

Wasmtime GitHub notifications bot (May 20 2026 at 22:15):

:speech_balloon: tschneidereit created PR review comment:

I don't think we can really do meaningfully better than this: there is no way to reliably tie a line printed to stdout/err back to a connection within an instance if multiple are in flight concurrently, since tasks from any of them might be processed freely and with arbitrary scheduling, or even without a Component Model task being visible at all. E.g. if for two incoming requests timer-based actions are used, they might be coalesced into a single external async task representing the closest deadline.

Wasmtime GitHub notifications bot (May 23 2026 at 11:53):

:speech_balloon: alexcrichton created PR review comment:

I think I already asked this, so forgive me that I've forgotten the answer, but how disruptive do you think it would be to change ErrorCode here to wasmtime::Error?

Wasmtime GitHub notifications bot (May 23 2026 at 11:53):

:thumbs_up: alexcrichton submitted PR review:

Given that this doesn't regress existing behavior i personally think this is reasonable to land and mostly figure out the logging/etc in the CM issue (thanks Pat for opening!).

Otherwise Joel and I worked through this ahead of time as well and everything looks reasonable here to me, too. Thanks @dicej!

Wasmtime GitHub notifications bot (May 23 2026 at 11:53):

:speech_balloon: alexcrichton created PR review comment:

This looks like it's missing #[cfg] on this branch, and given that CI is passing it probably means we don't actually check that you can build wasmtime-wasi-http without either feature... Mind putting the #[cfg] here and perhaps filing an issue about testing the conditional compile in CI in a future PR?

Wasmtime GitHub notifications bot (May 26 2026 at 22:10):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (May 26 2026 at 22:10):

:speech_balloon: dicej created PR review comment:

I'll look into it.

Wasmtime GitHub notifications bot (May 26 2026 at 22:29):

dicej updated PR #13404.

Wasmtime GitHub notifications bot (May 26 2026 at 22:38):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (May 26 2026 at 22:38):

:speech_balloon: dicej created PR review comment:

https://github.com/bytecodealliance/wasmtime/pull/13488

Wasmtime GitHub notifications bot (May 26 2026 at 22:50):

dicej updated PR #13404.

Wasmtime GitHub notifications bot (May 26 2026 at 22:50):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (May 26 2026 at 22:50):

:speech_balloon: dicej created PR review comment:

Done.

Wasmtime GitHub notifications bot (May 26 2026 at 22:58):

dicej updated PR #13404.

Wasmtime GitHub notifications bot (May 27 2026 at 00:05):

dicej added PR #13404 refactor wasmtime_wasi_http::handler to the merge queue

Wasmtime GitHub notifications bot (May 27 2026 at 01:26):

github-merge-queue[bot] removed PR #13404 refactor wasmtime_wasi_http::handler from the merge queue

Wasmtime GitHub notifications bot (May 27 2026 at 13:37):

dicej updated PR #13404.

Wasmtime GitHub notifications bot (May 27 2026 at 13:38):

dicej has enabled auto merge for PR #13404.

Wasmtime GitHub notifications bot (May 27 2026 at 13:47):

dicej added PR #13404 refactor wasmtime_wasi_http::handler to the merge queue

Wasmtime GitHub notifications bot (May 27 2026 at 14:12):

:check: dicej merged PR #13404.

Wasmtime GitHub notifications bot (May 27 2026 at 14:12):

dicej removed PR #13404 refactor wasmtime_wasi_http::handler from the merge queue

Last updated: Jun 01 2026 at 09:49 UTC