Repository navigation
Handling/forwarding error-contexts that can be generated during a body.finish #794
Description
During some implementation for error-contexts in futures in the wasip3-prototyping repo, we found that there was an issue with wasi:http/types#body.finish, as it implicitly does a future.read which can return a value or an error-context in the case of an error.
There are a few ways that we can solve this (thanks to @rvolosatovs and @dicej for suggestions), but a short incomplete list follows:
- Change the
finishmethod signature fromresult<option<trailers>, error-code>toresult<option<result<trailers, error-context>>,error-code> - Absorb the error and convert it into an existing
error-code(likelyinternal-error) - Create a new
error-codevariant that stores anerror-context
(1) is a reasonable approach but pollutes the type and possibly unreasonably forces caller to handle the error-context directly.
(2) causes some loss of context in an almost certain future version of error-context -- the best example is of an error context that can hold multiple traces (similar to an anyhow::Error), if we were to boil down the error context into only a string (given the current variants for error-code)
(3) Seems like an ideal option as a variation of (2) -- an additional error variant like internal-error-context(error-context) which would
There are of course other ways to handle this, so I'd like to open this up to discussion before submitting a PR to make the change (going for WebAssembly/wasi-http#3)
Activity
[-]Handling/forwarding `error-context`s that can be forwarded during a `body.finish`[/-][+]Handling/forwarding `error-context`s that can be generated during a `body.finish`[/+]lukewagner commentedon Feb 10, 2025
Great question!
In the medium term (in some 0.3.x release), one idea @sunfishcode had that I really like is that
resultshould include an impliciterror-contextin the error case (as-if, thusresult<T,U>would work at the ABI-level likeresult<T, tuple<U, error-context>>). (Since this would change the CABI ofresult, so we'd need to use somecanonoptopt-in to preserve backwards compatibility during the transition.) If we had already made this change, then, becausefinishreturns aresult<..., error-code>, we could simply propagate the internal future'serror-contextalong with the appropriateerror-code.In the short term, maybe it's fine to simply let the
error-contextdrop, with the understanding that later we'll be able to propagate it? Otherwise, we could stick anerror-contextsomewhere explicitly, but this will be something we'll want to deprecate later, so I'm not sure if it's worth the churn. Happy to hear other thoughts though.vados-cosmonic commentedon Feb 11, 2025
Thanks for the feedback @lukewagner !
The idea of
results always coming with anerror-contextis really interesting -- this makes sense to me in a world whereerror-contextis the way the underlying system expresses errors (which is an interesting concept for many reasons).One thing that makes me hesitate about that is the possible difficulty of intuiting that an
error-contextwould come with everyresult/knowing what that was/forcing implementation oferror-contextto implementresult. I think the WYSIWYG-ity of WIT as it stands now is really impressive (even if verbose at times), and being able to really easily map types to $LANGUAGE in the head of a new developer to the ecosystem is important -- and this might make that just a tad harder.Yeah definitely want to hear what others think here. There are so many ways to go about this.
Another thing that I forgot to mention that @dicej brought up is that we could actually not preemptively fetch the trailers for people and return them to the users to decide what to do with. We're at such a low level that I think that this might be really compelling as well.
vados-cosmonic commentedon Feb 13, 2025
After chatting with @pchickey , the idea of allowing the caller to decide whether they want to listen for trailers seems to be the best option -- i.e. not pulling trailers inside the
finishand instead returning afuture<option<trailers>>that callers can use if they so choose.Any thoughts @lukewagner ? I neglected to mention this suggestion in the first comment.
lukewagner commentedon Feb 17, 2025
@vados-cosmonic That sounds like a reasonable alternative interface, esp. if it obviates the root issue.
vados-cosmonic commentedon Feb 19, 2025
OK, got something up that implements this -- while I was going, I realized that the only case that seems reasonable for returning an
error-codefrombody.finishis actually if you're resolving the trailers -- so it looks like we don't even need the outerresult.WIT change:
WebAssembly/wasi-http#154
Upstream impl:
https://github.com/bytecodealliance/wasip3-prototyping/pull/16/files