wasmtime / PR #11127 implement Component Model async ABI · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #11127 implement Component Model async ABI

Wasmtime GitHub notifications bot (Jun 24 2025 at 17:19):

dicej opened PR #11127 from dicej:cm-async-implementation to bytecodealliance:main:

This commit replaces the stub functions and types in wasmtime::runtime::component::concurrent and its submodules with the working implementation developed in the wasip3-prototyping repo. For ease of review, it does not include any new tests; I'll add those in a follow-up commit.

Note that this builds on #11114 and #11123; only the third commit is new.

Wasmtime GitHub notifications bot (Jun 24 2025 at 17:19):

dicej requested wasmtime-fuzz-reviewers for a review on PR #11127.

Wasmtime GitHub notifications bot (Jun 24 2025 at 17:19):

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

Wasmtime GitHub notifications bot (Jun 24 2025 at 17:19):

dicej requested fitzgen for a review on PR #11127.

Wasmtime GitHub notifications bot (Jun 24 2025 at 17:19):

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

Wasmtime GitHub notifications bot (Jun 24 2025 at 17:19):

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

Wasmtime GitHub notifications bot (Jun 24 2025 at 17:23):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jun 24 2025 at 18:36):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jun 24 2025 at 18:37):

dicej requested alexcrichton for a review on PR #11127.

Wasmtime GitHub notifications bot (Jun 26 2025 at 22:58):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jun 27 2025 at 15:48):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jun 27 2025 at 18:49):

github-actions[bot] commented on PR #11127:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "fuzzing", "wasmtime:api", "wasmtime:c-api"

Thus the following users have been cc'd because of the following labels:

fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Jun 30 2025 at 15:03):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jun 30 2025 at 15:20):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jun 30 2025 at 16:14):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:00):

alexcrichton commented on PR #11127:

@dicej on this one thing I want to write down before I forget (I've forgotten this many times so far...)

Index allocation for futures/streams/error-context I believe are going to need to be updated here. I believe the current state of this PR is such that there's one indexing namespace for all resources within a component, and then there's another index namespace for futures/streams/error-context. Spec-wise I believe it's required we unify these index namespaces. I realize that this is an artifact of the history of the implementation here, but it's something that I want to be sure to write down and not forget.

Effectively my naive expectation would be that this type grows to include Stream/Future/ErrorContext variants and a table or similar in ConcurrentState will end up being removed.

Wasmtime GitHub notifications bot (Jul 01 2025 at 22:01):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 02 2025 at 14:58):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 02 2025 at 15:46):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 02 2025 at 15:50):

alexcrichton commented on PR #11127:

Another thought I've now had which I don't want to forget: this is introducing a significant #[cfg] in the path of calling a component function with the async style. That means that the non-cm-async implementation will be entirely untested in CI which is not an ideal state to be in. I don't know how best to handle this but I wanted to note it before I forget.

Wasmtime GitHub notifications bot (Jul 02 2025 at 19:33):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 02 2025 at 21:14):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 02 2025 at 21:16):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 03 2025 at 23:15):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jul 04 2025 at 03:45):

dicej edited PR #11127:

This commit replaces the stub functions and types in wasmtime::runtime::component::concurrent and its submodules with the working implementation developed in the wasip3-prototyping repo. For ease of review, it does not include any new tests; I'll add those in a follow-up commit.

Wasmtime GitHub notifications bot (Jul 07 2025 at 14:37):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 07 2025 at 15:02):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 07 2025 at 15:58):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:32):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton submitted PR review:

Ok I've gone through all of concurrent.rs and here's comments here and there. I haven't looked at futures_and_streams yet and I'll want to closely review the unsafe traits there though, so more to come.

I've also pushed up a few commits here for miscellaneous things, so feel free to squash them all in if you're ok with them or append further commits here.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

IIRC this file is a duplicate of vm/component/resources.rs right? (or at least a historic one). IIRC we talked about deferring resolving this duplication to later, but mind filing an issue and registering a FIXME here?

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

I manually changed the previous PR, but mind updating the import style in the new files to match the preexisting style in Wasmtime?

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

Mind either (a) resolving this TODO in this PR or (b) filing an issue for this TODO to point to and pointing to that?

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

Mind filing an issue for this?

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

Like above, can this be pub(crate)

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

Can you file an issue about removing to_vec here? I'm remembering now that while I synchronized the async/concurrent signature in Linker for dynamic things I think that's something we're going to want to do here as well for call_concurrent. The signature will change slightly but I think it will still be doable (and like the linker ones it'd use Vec internally for now)

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

Could this be done by removing the task on Drop instead of allocating an extra Arc?

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

Could this be made pub(crate)?

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

Are these perhaps relics of a historical implementation? (similar with methods above). I'd otherwise imagine that the method-based accessors could all get removed in favor of accessing the fields directly

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

I'm wary of this in that we don't want to change the public API contract required depending on crate features being enabled or disabled. This implementation looks like it goes from requriing post_return to not requiring it, which would be a regression for the public API. Could this be integrated differently to still require post return when call_async is used? (it's fine to me that call_concurrent is documented as not requiring post-return)

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

Mind removing this and replacing it with Waker::noop()?

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

We'll want to do something about this (e.g. document, remove, etc).

In toying around locally though I see that the reason for this is Vec<HostTaskFuture> which is only Send, not also Sync. I think we'll want to keep that in the sense that we don't want to require futures to all be both Sync and Send, only Send, if possible.

Also in toying with this though I can remove the spawned_tasks field entirely and tests all pass. Given that do you know of a reason to keep this field, and if not can it be removed? (once removed it's possible to remove these unsafe impl blocks)

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:33):

alexcrichton created PR review comment:

Also, mind running some of the basic, typed, no-call-hook, etc, benchmarks for host-to-wasm to see the impact of this new code path?

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:49):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:49):

dicej created PR review comment:

This is intentionally public to allow host function implementations to call Instance::{future,stream}, for which they need an Instance object.

Given that Instance is Copy, I suppose we could require the host function closure to close over an Instance from the top-level code (i.e. the code that actually creates the instance). The ergonomics wouldn't be as nice, though, plus it creates the hazard that the host embedder code mixes up its Instances and closes over the wrong one.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:49):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:49):

dicej created PR review comment:

See my reply above.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:51):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:51):

dicej created PR review comment:

I think I just got carried away with writing accessor methods; I can get rid of them.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:54):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:54):

dicej created PR review comment:

Also in toying with this though I can remove the spawned_tasks field entirely and tests all pass

Sounds like we're missing test coverage, then -- probably because we were leaning on the wasmtime-wasi[-http] integration tests to exercise this and never wrote any non-wasi tests for it. I'm sure some of the wasi tests will fail if you remove that field.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:58):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 16:58):

dicej created PR review comment:

Could this be done by removing the task on Drop instead of allocating an extra Arc?

I had originally planned to do that, but couldn't see how to avoid shared mutable aliasing of the store. Revisiting it now, I can see we just need a custom Future implementation which has a StoreContextMut field, similar to what we did for FiberFuture. I'll do that.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:00):

dicej created PR review comment:

BTW, I'm fine with changing the field to a Mutex<Vec<HostTaskFuture>> if that's what we need to remove the unsafe impls.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:00):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:30):

dicej created PR review comment:

Can you elaborate on how you'd like to see this code changed? Naively, I could imagine changing this to look more like TypedFunc::call_async, but that would require the same unsafe use of a raw pointer, which I was trying to avoid here.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:30):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:46):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:46):

alexcrichton created PR review comment:

Ideally we'd have fn call_concurrent<'a>(self, store: ..., params: &'a [Val], results: &'a mut [Val]) -> Pin<Box<... + 'a>> where the returned future would close over params and results. Internally that'd do something like Linker::func_new_concurrent where Vec is still used internally to satisfy the 'static needed to put the future into the store but otherwise the public signature wouldn't change.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:50):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:50):

alexcrichton created PR review comment:

This sort of API makes it very similar to Caller that we have for core wasm which is something I've long wanted to delete from the public API, but it's pretty load-bearing so we probably can't remove that. I've historically wanted to resist any similar temptation to add such a similar call to components as well (e.g. there's no Caller on any component::Linker methods, it's all just StoreContextMut).

I'll try to revisit this when reading over futures and streams code and see if I can't formulate more thoughts about this.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:51):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 17:51):

alexcrichton created PR review comment:

Currently in this PR there are no reads of the spawned_tasks field which is why tests in the cm-async-tests PR (which I realize doesn't include wasmtime-wasi{,-http}) pass. Does this mean that some changes from upstream wasip3-prototyping accidentally weren't merged back here?

Wasmtime GitHub notifications bot (Jul 07 2025 at 18:00):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 18:00):

dicej created PR review comment:

Currently in this PR there are no reads of the spawned_tasks field

Maybe I'm misunderstanding, but isn't this a read of that field?

Wasmtime GitHub notifications bot (Jul 07 2025 at 18:01):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jul 07 2025 at 18:05):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jul 07 2025 at 18:29):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 18:29):

alexcrichton created PR review comment:

Er yes, bad words on my part. Basically nothing ever pushes on that vector so it's always empty

Wasmtime GitHub notifications bot (Jul 07 2025 at 19:45):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 07 2025 at 19:45):

dicej created PR review comment:

Ok, then yes, this looks like dead code. We used to push spawned tasks to a vector in Access[or]::spawn but now we call Instance::spawn_with_accessor instead, so you're right that the field can be removed. I'll do that.

Wasmtime GitHub notifications bot (Jul 07 2025 at 19:57):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jul 07 2025 at 23:59):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jul 08 2025 at 00:16):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 08 2025 at 00:16):

dicej created PR review comment:

I've pushed an update to require post_return_async for call_async and added docs to call_concurrent indicating that the post-return function is called automatically in that case.

Wasmtime GitHub notifications bot (Jul 08 2025 at 13:47):

dicej created PR review comment:

Also, mind running some of the basic, typed, no-call-hook, etc, benchmarks for host-to-wasm to see the impact of this new code path?

Would you mind providing instructions for doing that? I ran cargo bench, but that ran a bunch of other, irrelevant stuff as well. How did you get your "before vs. after" numbers on the last PR, and how did you specify which ones to run?

Wasmtime GitHub notifications bot (Jul 08 2025 at 13:47):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 08 2025 at 14:32):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 08 2025 at 14:32):

alexcrichton created PR review comment:

Oh sure yeah, I do:
cargo bench --bench call -- --list
first, and then this accepts a regex argument to pare down what's being run so I build up a regex to just the benchmarks that are relevant. For example
cargo bench --bench call -- --list '^sync.*component'
focuses just on sync calls (the fastest ones) and component-related ones. Here we only want host-to-wasm
cargo bench --bench call -- --list '^sync.*component.*host-to-wasm'
and eventually what you probably want to run is:
cargo bench --bench call -- --list '^sync/no-hook.*component.*host-to-wasm.* typed .*'

Wasmtime GitHub notifications bot (Jul 08 2025 at 14:33):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 08 2025 at 14:33):

alexcrichton created PR review comment:

What I'd also recommend is using
$previous_command --save-baseline main
on the main branch or without the component-model-async feature. Then with this PR you'd run:
$previous_command --baseline main
which will automate criterion reporting differences to the previously captured baseline

Wasmtime GitHub notifications bot (Jul 08 2025 at 14:35):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 08 2025 at 14:41):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 08 2025 at 15:07):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:43):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton updated PR #11127.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

I think this wants to further type-check that the payload type matches T, e.g. T::typecheck(...)

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

Would it be possible to change all these watch_* methods to async fn watch(&mut self) { ... }? That I think is a simple signature to model the various interactions here:

By taking &mut self it's effectively "taking ownership", aka preventing anything else happening.

Watch::into_inner is now dropping the returned future.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

Here "write end dropped without writing" is a documentation-of-eld, right?

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

Along the lines of a comment about async fn above, I think this would be much clearer as a loop over the buffer calling self.write rather than via recursion.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

Wherever possible I personally find it much easier to reason about/read async fn signatures rather than those returning impl Future. Would it be possible to change this, and a number of other functions in this file that just return impl Future to async fn? I believe the Send-ness of the future here will be correctly inferred.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

Like writers above, could this be an async fn with &mut self as a receiver?

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

Similar to above the payload here needs to be type-checked against T

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

Similar to futures above I think this rep needs to be type-checked against T

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

This trait, and ReadBuffer below, show up in public trait bounds so these need to be public documented traits. Ideally with links to what methods use them and such.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

Would it be possible to have this be &mut self? I realize that would mean changing how "things are dropped" is modeled but personally I find that style of ownership much easier to work with than the move-in-and-move-out style this is currently using.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

FWIW I find the terminology here pretty confusing. I understand you pass a ReadBuffer to a read operation, but the only thing you can do with a ReadBuffer is write to it. I have not spent much time trying to find better names, but I wanted to write this down nonetheless.

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

My understanding is that this is not intrinsic to the feature, is that right? This is only here for the {Take,Read,Write}Buffer implementations?

If so can this be made an optional feature to avoid requiring it?

Wasmtime GitHub notifications bot (Jul 08 2025 at 17:49):

alexcrichton created PR review comment:

There's no protections here that T is correct?

Wasmtime GitHub notifications bot (Jul 09 2025 at 19:42):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jul 09 2025 at 20:52):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 09 2025 at 20:52):

dicej created PR review comment:

I've replaced the Arc with code that removes the task when the future is resolved or dropped. I've also opened https://github.com/bytecodealliance/wasmtime/issues/11209 to track future optimization work.

Wasmtime GitHub notifications bot (Jul 09 2025 at 21:43):

dicej updated PR #11127.

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:41):

dicej created PR review comment:

Issue filed: https://github.com/bytecodealliance/wasmtime/issues/11218

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:41):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:42):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:42):

dicej created PR review comment:

Issue filed: https://github.com/bytecodealliance/wasmtime/issues/11219

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:43):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:43):

dicej created PR review comment:

Issue filed: https://github.com/bytecodealliance/wasmtime/issues/11219

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:43):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:43):

dicej created PR review comment:

Issue filed: https://github.com/bytecodealliance/wasmtime/issues/11219

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:43):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:43):

dicej created PR review comment:

Issue filed: https://github.com/bytecodealliance/wasmtime/issues/11219

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:45):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 14:45):

dicej created PR review comment:

Yeah, I struggled with the names of WriteBuffer and ReadBuffer, too. What about SourceBuffer and DestinationBuffer instead?

Wasmtime GitHub notifications bot (Jul 11 2025 at 17:56):

alexcrichton created PR review comment:

I'm going to defer this to https://github.com/bytecodealliance/wasmtime/issues/11223

Wasmtime GitHub notifications bot (Jul 11 2025 at 17:56):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 18:01):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 18:01):

dicej created PR review comment:

I've opened an issue for this: https://github.com/bytecodealliance/wasmtime/issues/11222

Wasmtime GitHub notifications bot (Jul 11 2025 at 18:01):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 18:01):

dicej created PR review comment:

I've opened an issue for this: https://github.com/bytecodealliance/wasmtime/issues/11222

Wasmtime GitHub notifications bot (Jul 11 2025 at 18:01):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 18:01):

dicej created PR review comment:

I've opened an issue for this: https://github.com/bytecodealliance/wasmtime/issues/11222

Wasmtime GitHub notifications bot (Jul 11 2025 at 20:34):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 20:34):

dicej created PR review comment:

Issue filed: https://github.com/bytecodealliance/wasmtime/issues/11219

Wasmtime GitHub notifications bot (Jul 11 2025 at 20:35):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 20:35):

dicej created PR review comment:

I've opened an issue for this: https://github.com/bytecodealliance/wasmtime/issues/11222

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:00):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:00):

dicej created PR review comment:

Issue filed: https://github.com/bytecodealliance/wasmtime/issues/11226

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:01):

dicej created PR review comment:

Issue filed: https://github.com/bytecodealliance/wasmtime/issues/11226

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:01):

dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:05):

alexcrichton submitted PR review:

Ok I believe we've filed issues for follow-up tasks but otherwise this is an off-by-default feature and in a pretty good spot otherwise, so I'm going to flag for merge. Thanks again @dicej!

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:29):

alexcrichton merged PR #11127.

Last updated: Dec 06 2025 at 07:03 UTC