Defer `error-context` to after 0.3.0

[alexcrichton]

I talked today with a few folks and I wanted to write up our thoughts/conclusions into an issue to get some wider feedback before sending a PR to commit to anything. The basic premise is:

• Emoji-gate error-context in the explainer document.
• Remove error-context arguments/integration with futures/streams.

In effect this would defer integration with error-context until after WASI 0.3.0 has shipped and make error-context a future addition to WIT and the component model.

---

Ok, but why? The original motivation for considering this comes from me considering current issues such as #469 and #472. Overall, in my opinion at least, some changes are needed in the spec with respect to error-context. While these can be fixed and resolved in isolation I wanted to bring up a possible broader context of: can we defer it entirely until after 0.3.0?

In talking with @lukewagner one of the chief desires of error-context is eventual future integeration with the WIT result type. For example when constructing one you could supply an error-context or when receiving one you could optionally acquire an error-context. Currently result does not have this integration so it'll have to be designed in a backwards-compatible fashion, and the theory is that such backwards-compatible infrastructure could be equally applied to streams/errors as well.

---

There's a lot of other various inter-related things that were discussed around this, but that's the crux of the issue effectively. I wanted to open this up before making a PR with the actual changes to get some broader discussion. I know that @vados-cosmonic is probably likely interested in this, and various WASI folks as well.

[lukewagner]

Makes sense to me. Just to add a bit more explanation:

The design of error/error-context has evolved in several steps, starting from a point where we expected it to be an explicit part of most fallible WIT function types and then evolving to the current design where error-context is implicitly a part of the error cases of future and stream (and, later, result) while the WIT error payload types are explicit parts of the type (currently via the verbose tuple<stream<T>, future<result<U, E>>> pattern and hopefully in the future via a more-succinct stream<T, U, E>). Thus, the original pressing necessity (to answer: "how do errors work with futures/streams?") is no longer quite so pressing as to require being in 0.3.0.

One reason that it's attractive to hold off on error-context in 0.3.0 is that it avoids the current asymmetry where result doesn't have an implicit error-context and so you might be tempted to add one explicitly (via result<T, tuple<E, error-context>>), leading to double error-contexts when we add them implicitly in the future. Instead, we can avoid the whole (WASI-design) question in the 0.3.0 timeframe and then add error-contexts (backwards-compatibly, opt-in) consistently at the same time in the future to stream, future and result.

[vados-cosmonic]

Hey @alexcrichton thanks for writing all this up and @lukewagner for weighing in-- I agree with what's been discussed in this thread so far (I was also a proponent of separating out the impl of errors into a 2.x release). The only question I guess I have is what we'll do instead.

wasi:io's error had a few issues (bytecodealliance/wit-bindgen#812 sticks out the most for me, though it's more of a bindgen bug than anything), but will we just be using locally define variants to represent the errors in the appropriate scenarios for P3?

[rvolosatovs]

I think it's a great idea to defer error-context, there are definitely still a few things to figure out before committing to it.

Like @lukewagner pointed out, we already pair all fallible streams with a future<result<U, E>>, in the interface definitions anyway (where U and E are interface-specific), for example:

• wasi:sockets/types.tcp-socket#receive
• wasi:filesystem/types.descriptor#read-via-stream

So the guests are always expected to await the result future and that's how they get to know whether the stream was closed successfully or not.

The only question I guess I have is what we'll do instead.

I think we just keep doing what we're already doing, pairing fallible streams with a future<result<U, E>>.

I think we could adopt the following set of guidelines:

Infallible streams

Example of such a stream would be a stream of ticks produced by the host clock.

• time.Tick in Go
• tokio::time::Interval in Rust paired with a tokio_stream::wrappers::IntervalStream

Such a stream cannot fail, in other words, it cannot be closed with an error. For such cases we simply use stream<T>

Fallible streams

Such streams are likely tied to I/O, for example:

• wasi:sockets/types.tcp-socket#receive
• wasi:filesystem/types.descriptor#read-via-stream

On consumer side/in return position we'll use tuple<stream<T>, future<result<U, E>>> or analogous construct (e.g. these could be fields in the record) to represent these. Consumers then are expected to always await the returned future.

• The returned future will be pending as long as stream is not exhausted, in other words, future will be pending as long as stream.read has not reported the stream as closed.
• Once call to stream.read has reported the stream as closed, the future becomes ready.
• If the future resolves to ok(U), then the stream was closed successfully with the final element U
• If the future resolves to err(E), then the stream was closed with an error E

We will have to use a similar construct on producer side/in parameter position, for example,

with-fallible-stream: func(data: stream<u8>, res: future<result>);

In case of success, caller of with-fallible-stream will have to send ok on provided future after closing the stream
In case of an error, caller of with-fallible-stream will have to send err on provided future after closing the stream

[alexcrichton]

These are excellent points @vados-cosmonic and @rvolosatovs and ones I had forgotten about. I'm not opposed to stream/future pairs myself but I regardless agree that this would be a consequence of decoupling error-context from streams/futures.

Another possible idea as an alternative is that conventionally whatever thing you got the stream from also has a method for getting an error. For example:

resource tcp-socket {
  receive: func() -> stream<u8>;
  receive-error: func() -> option<error-code>;
}

This might be a bit easier to implement from a host point of view and may not be too much of a burden on guests trying to bind this either as they're likely to keep both the stream and socket around to work on. In the future if error-context gets auto-attached to the stream<u8> return value (optionally) with future component model additions we could in theory then deprecate the receive-error function and say to use the error-context instead (and have something like func(error-context) -> option<error-code>)

[rvolosatovs]

say to use the error-context instead (and have something like func(error-context) -> option<error-code>)

From what I understood talking to @lukewagner we actually explicitly don't want this mapping to exist, since error-context is meant to be more of a "trace", "human readable error" or even "log statement".

At least in the context of streams of futures, the future we're moving towards is stream<T, U, V>, where streams finish with either U (success) or V (failure).
For example, for wasi:http, we are hoping to be able to replace body resource by:
stream<u8, trailers, error-code>.

Streams would also have functionality like split, roughly:

split :: Stream<T, U, V> -> Tuple<Stream<T, (), ErrorContext>, Future<U, V>>

for example, in pseudo-Rust:

fn handle(in: Stream<u8, T, IOError>) {
    let (in_data, in_final): (Stream<u8, (), ErrorContext>, Future<T, IOError>) = in.split();
    let (data, final) = in_data.collect().await;
    let cx = match final {
        Ok(()) => return,
        Err(cx) => {
          // cx is the error context
          cx
        },
    };
    let Err(err) = in_final.await else {
      unreachable!()
    };
   // `err` has the same error context attached to it as the one represented by `cx`
}

[alexcrichton]

That all makes sense yeah, although I'm a bit skeptical of the complexity necessary to implement the future/stream combo on the host. If you've already done it then seems ok, but my gut is it's not going to be easy to model. That's where I was thinking a method-on-resource might be reasonable, and we can entirely discard the idea of getting an error-code from a resource as that's unrelated.

[rvolosatovs]

That all makes sense yeah, although I'm a bit skeptical of the complexity necessary to implement the future/stream combo on the host. If you've already done it then seems ok, but my gut is it's not going to be easy to model. That's where I was thinking a method-on-resource might be reasonable, and we can entirely discard the idea of getting an error-code from a resource as that's unrelated.

I've done it a few times, indeed, and (given some refactoring at least to get rid of the indentation levels) it does not seem that bad e.g.:

• https://github.com/bytecodealliance/wasip3-prototyping/blob/93061d15653d89cdc15c54ac22b8e4d8d5861cdc/crates/wasi/src/p3/sockets/host/types/tcp.rs#L425-L491
• https://github.com/bytecodealliance/wasip3-prototyping/blob/93061d15653d89cdc15c54ac22b8e4d8d5861cdc/crates/wasi/src/p3/filesystem/host.rs#L53-L134

note, that both of these examples are pretty special with complex state transitions/interface-specific semantics, I expect implementations of "regular" APIs to be much simpler.

I think individual stream and future types would also be more composable and align better with the future stream<T, U, V>.