finish-{in|out}going-stream should each return a (pseudo-)future which resolves to a result

[dicej]

We're wrapping up our implementation of wasi-http for Spin, and noticed a few issues, including this one. Given that finish-outgoing-stream takes an option<trailers> and finish-incoming-stream returns the same, both of them need to do I/O, which should happen asynchronously and be fallible like all other I/O in the proposal.

In the case of finish-incoming-stream, we can work around the issue by reading the trailers implicitly as part of the last streams::read call on the body and then keep it around until finish-incoming-stream is called. That's what our implementation currently does, but there are drawbacks:

• If there's an error reading the trailers, we have no way to report it except when the app thinks it's still reading the body, which feels wrong.
• There's significant extra bookkeeping and state management involved: https://github.com/fermyon/spin/blob/132a32daed6632768d52a9336125073e87fee1e8/crates/wasi-cloud/src/streams.rs#L29-L128

In the case of finish-outgoing-stream, we can again work around the issue by spawning a task that writes the trailers, but again we have no obvious way of reporting any errors that occur, and the application has no way of knowing when the trailers have actually made it to the network, successfully or otherwise.

Alternatively, we could declare that both calls block, but that would be odd considering everything else is asynchronous, and we're still left with the question of how to report I/O errors.

I realize that this whole issue may end up being irrelevant once we have real streams, but that's a long way away from what I understand.

Thoughts?

[lukewagner]

Agreed! Great catch, that is indeed an oversight. I'll make a PR adding this in a bit.

[lukewagner]

I took a stab at fixing this in #37, PTAL.