Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incoming-request-* should return Result<foo> #16

Open
brendandburns opened this issue Mar 22, 2023 · 2 comments
Open

incoming-request-* should return Result<foo> #16

brendandburns opened this issue Mar 22, 2023 · 2 comments

Comments

@brendandburns
Copy link
Contributor

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)

@pchickey
Copy link
Contributor

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

@lukewagner
Copy link
Member

(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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants