Add async call stacks to the public API, use it in wasi:http#13510
Merged
alexcrichton merged 5 commits intoJun 4, 2026
Conversation
This commit adds a few new APIs to the surface area of the `wasmtime`
crate as well as reorganizes some internals. Namely:
* `StoreContextMut::async_call_stack` - yields an `Iterator` of the call
stack of async tasks in the component model to understand the current
call graph.
* `{Typed,}Func::{start,finish}_call_concurrent` - these new APIs allow
splitting apart the previous `call_concurrent` function into discrete
steps to learn about the task being created, notably the
`GuestTaskId`. The previous `call_concurrent` is reimplemented in
terms of these functions.
* Methods requiring the `component-model-async` Cargo feature are now
under the `concurrent` module in `wasmtime` to cut down on `#[cfg]`
required.
This is all intended to address the concerns of WebAssembly/WASI#918,
WebAssembly/WASI#919, and WebAssembly/WASI#920. This isn't plumbed into
wasi-http yet, but that'll come as a
This commit uses the previous commit to connect a generic, host-defined, request ID and provide a strong connection to the `GuestTaskId` that's being used to serve that request. This can be used by `wasi:http` handlers to provide a strong correlation between outgoing requests, for example, and incoming requests.
alexcrichton
force-pushed
the
wasi-http-changes
branch
from
960a49e to
ff70a0f
Compare
dicej
approved these changes
Jun 3, 2026
| /// An opaque unique identifier that hosts can assigned to requests which is | ||
| /// threaded from [`ProxyHandler::handle`] into | ||
| /// [`WorkerState::on_request_start`] | ||
| type RequestId: Send + Sync; |
Contributor
There was a problem hiding this comment.
I'll just note that Extensions is another way to attach arbitrary data to a Request. This is likely more efficient, though.
Member
Author
There was a problem hiding this comment.
Oh I had no idea about that! I'll try to stick to RequestId for now but if it becomes too onerous we can switch to that.
Co-authored-by: Joel Dice <joel.dice@akamai.com>
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is intended to be the Wasmtime-specific resolution of WebAssembly/WASI#918, WebAssembly/WASI#919, and WebAssembly/WASI#920. Two commits are included here, both of which have more details as to what they're doing. At a high level though the first commit is providing the primitives in the
wasmtimecrate's API to reflect on the async call stack as defined by the component model. The second commit then refactors ourwasmtime servehandling to thread this through and provide the host with a strong guarantee of "this request is being served on this store with this task", which is intended to then enable the store to do whatever it likes in terms of handling.