feat(proxy-wasm) invoke 'on_http_call_response' on dispatch failures #625
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #625 +/- ##
===================================================
+ Coverage 90.69893% 90.83481% +0.13588%
===================================================
Files 52 52
Lines 11117 11260 +143
===================================================
+ Hits 10083 10228 +145
+ Misses 1034 1032 -2
... and 6 files with indirect coverage changes
Flags with carried forward coverage won't be shown. Click here to find out more.
|
thibaultcha
force-pushed
the
feat/catch-dispatch-failures
branch
24 times, most recently
from
182bb79
to
eb13e45
Compare
I assume that this is in an interim solution until we can get something like |
Yes, and I looked into this and it was unclear how to contribute this at first sight, so I logged it for later. It looks to me like |
thibaultcha
force-pushed
the
feat/catch-dispatch-failures
branch
3 times, most recently
from
8ed89d9
to
7880974
Compare
| } | ||
| } | ||
| --- response_body_like | ||
| :dispatch_status: timeout |
There was a problem hiding this comment.
@hishamhm This version will support get_http_headers and return the :dispatch_status pseudo-header in the table
Invoke `on_http_call_response` on dispatch connection failures. This
allows catching failures such as:
- timeout
- broken connection
- resolver failures
- TLS handshake failures
- Any other failures *after the connection has attempted to be
established*
Dispatch failures occurring *before* a connection has attempted to be
established will not trigger `on_http_call_response` as they are already
supposed to trigger a Wasm exception (i.e. trap).
When a dispatch connection failure occurs, `on_http_call_response` is
invoked with: `on_http_call_response(call_id, 0, 0, 0)` (i.e. no header,
no body, no trailers). Calls to retrieve the response `:status` will
return `None`. A user may triage the connection failure by querying the
`:dispatch_status` pseudo-header:
```rust
fn on_http_call_response(
&mut self,
token_id: u32,
nheaders: usize,
body_size: usize,
ntrailers: usize,
) {
let dispatch_status = self.get_http_call_response_header(":dispatch_status");
match dispatch_status.as_deref() {
Some("timeout") => {},
Some("broken connection") => {},
Some("tls handshake failure") => {},
Some("resolver failure") => {},
Some("reader failure") => {},
Some(s) => info!("dispatch_status: {}", s),
None => {}
}
self.resume_http_request()
}
```
The socket status `"bad argument"` also exists but since the connection
has not been attempted yet, it won't show up during
`on_http_call_response` and is for internal use only (i.e. could be
added to the socket error log for example).
Fix #622.
thibaultcha
force-pushed
the
feat/catch-dispatch-failures
branch
from
7880974
to
a3d0e43
Compare
Invoke
on_http_call_responseon dispatch connection failures. This allows catching failures such as:Dispatch failures occurring before a connection has attempted to be established will not trigger
on_http_call_responseas they are already supposed to trigger a Wasm exception (i.e. trap).When a dispatch connection failure occurs,
on_http_call_responseis invoked with:on_http_call_response(call_id, 0, 0, 0)(i.e. no header, no body, no trailers). Calls to retrieve the response:statuswill returnNone. A user may triage the connection failure by querying the:dispatch_statuspseudo-header:The socket status
"bad argument"also exists but since the connection has not been attempted yet, it won't show up duringon_http_call_responseand is for internal use only (i.e. could be added to the socket error log for example).Fix #622.
TODO
[ ] contributeproxy_get_status()for HTTP dispatch calls to proxy-wasm-rust-sdk