You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the incoming-request-{authority, path, scheme, etc} family of methods currently do not have a way to indicate that an error occurred when fetching the value (e.g. if the request id is unknown)
The text was updated successfully, but these errors were encountered:
Is the request id unknown the only possible error here? If so, we can make these fallible for now, but once we have resources, the request will be guaranteed to be valid when it crosses a component boundary (if a bad table index is passed to the cabi, the runtime will trap), so we'll want to note that the result is temporary until resources land
(sorry for slow reply; back now) As is, the CABI specifies traps (as if executing unreachable) in various cases that suggest fundamental toolchain bugs or corruption on the part of the guest (things like offset/length out of bounds, invalid UTF-8, etc). Once resources/handles are implemented, the CABI will similarly specify a trap when the i32 handle index is out-of-bounds w.r.t the associated table, so I think we should similarly say that is what happens in the current pre-handle state of the world.
Currently the
incoming-request-{authority, path, scheme, etc}
family of methods currently do not have a way to indicate that an error occurred when fetching the value (e.g. if the request id is unknown)The text was updated successfully, but these errors were encountered: