Wasmtime GitHub notifications bot (Nov 26 2025 at 02:54): Wasmtime GitHub notifications bot (Nov 26 2025 at 02:54):alexcrichton opened issue #12090:
Currently there's no API to, given a
FutureReader, perform a read and then cancel that read to get back the originalFutureReader.
Wasmtime GitHub notifications bot (Nov 26 2025 at 02:54):alexcrichton added the wasm-proposal:component-model-async label to Issue #12090.
Wasmtime GitHub notifications bot (Nov 26 2025 at 21:58):alexcrichton commented on issue #12090:
I'm realizing this is also applicable to streams. Another case that's not currently possible with streams is to read some items and then pass the stream back into wasm. Once a host starts reading a stream it can't stop at this time.
Wasmtime GitHub notifications bot (Dec 03 2025 at 20:27):alexcrichton commented on issue #12090:
To articulate this a bit more now that I've got more experience: here's a set of relate things you can't do with the current API:
- Start reading a
{Future,Stream}Readerthen cancel it to get back a{Future,Stream}Readerto pass back into wasm.- Start reading a
FutureReaderand somehow return "closed" to the caller. The current API ofFutureConsumeris such that "closed" is just not an option.
Wasmtime GitHub notifications bot (Oct 05 2026 at 08:52):Byte-Naut commented on issue #12090:
Building on your December comment: I've been thinking about how to implement the two gaps you described and wanted to check a few design questions before writing more code.
Write-end semantics: After the host cancels its read and gets back the reader, should the guest write end remain suspended — waiting for a new reader — rather than receiving
CANCELLED? My reading of the spec points to yes, but I'd like to confirm before building around it.Return type for cancellable reads: For the first gap, are you envisioning a new concrete type that wraps the reader (resolving to either the read result or the original reader on cancel), or something more like an optional guard on the existing
FutureReader/StreamReader?
FutureConsumerbreaking change: Addressing the "closed is not an option" gap seems to require changingFutureConsumer's return type. Would you prefer that landed in a small focused PR first, or folded into the cancellation work?No rush at all — happy to wait until you have a moment for this.
Wasmtime GitHub notifications bot (Oct 07 2026 at 22:00):alexcrichton commented on issue #12090:
Personally I'd say that this issue should probably wait until a concrete use case arises. There's a lot of possible design directions this could go in, with varying amounts of overhead, and it's something I feel would be best informed with a use case at-hand to figure out how best to tackle it. The original motivation here, a fuzzer I was writing, is no longer relevant.
Last updated: Oct 11 2026 at 05:07 UTC