-
Notifications
You must be signed in to change notification settings - Fork 1.5k
wasi-http: Implement http-error-code, and centralize error conversions #7534
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
wasi-http: Implement http-error-code, and centralize error conversions #7534
Conversation
crates/wasi-http/src/lib.rs
Outdated
pub fn http_request_error(err: http::Error) -> bindings::http::types::ErrorCode { | ||
use bindings::http::types::ErrorCode; | ||
|
||
tracing::warn!("http request error: {err:?}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize that this matches what I was talking about yesterday, where if an error is dropped on the floor it's always at least logged, but I will also say that there's quite a lot of logging going on here. In theory almost all error context should be made available to end users, but it seems like almost all errors are being dropped and canonicalized in bland error codes.
There's not really anything that can be done about that in this PR specifically, but it might be something good to keep in mind for future iterations of wasi-http. One possible example might be something like a "last error as debug string" API or something like that. Or alternatively using wasi:io/error.{error}
for all http APIs and then having an optional "pull out the http-specific error kind from each error" API sort of like filesystems. Too late to do this for preview2 but perhaps later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was going to be a bit noisy, so I've reworked it so that we only log on a path where there's not clear translation back to a wasi-http error (the fall-through cases). Looking more towards the future, I wonder if it would be better to return a wasi:io/error/error
instead of a wasi:http/types/error-code
. @pchickey and I started working on this last week, but held off on making this change as it was not as easy as swapping out uses of error-code
.
8507bfd
to
f7c6235
Compare
@elliottt is this something that should be backported to Wasmtime 15? |
bytecodealliance#7534) * Implement the missing http-error-code function * Add concrete error conversion functions * Test the error returned when writing too much * Remove an unused import * Only log errors when they will get the default representation * Use `source` instead of `into_cause`
Implement the body of
http-error-code
, and add a test that shows its use when writing too much. This functionality was missing from #7434.Additionally, add some functions in wasi-http for converting from hyper::Error and http::Error to the new
ErrorCode
variant. These functions log the error received as a warning, and return the translated error to the guest.