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
After #701, there are potentially two async tasks involved in request handlers:
the one in which hyper invokes us when a new request comes in. This one also runs the request handler if using HandlerTaskMode::CancelOnDisconnect.
if using HandlerTaskMode::Detached, the one in which the request handler runs
If the request is cancelled (e.g., if the client disconnects), the first of these tasks gets cancelled. With HandlerTaskMode::Detached, the request handler still runs to completion. Unfortunately, the "request completed" log entry USDT probes happen in the first of these contexts. So you don't get these events when the client request was cancelled. This makes it much harder to write correct DTrace scripts and also makes it much harder to debug from logs since you can't assume there's a "request completed" log entry for all requests that did essentially complete.
After #701, there are potentially two async tasks involved in request handlers:
HandlerTaskMode::CancelOnDisconnect
.HandlerTaskMode::Detached
, the one in which the request handler runsIf the request is cancelled (e.g., if the client disconnects), the first of these tasks gets cancelled. With
HandlerTaskMode::Detached
, the request handler still runs to completion. Unfortunately, the "request completed" log entry USDT probes happen in the first of these contexts. So you don't get these events when the client request was cancelled. This makes it much harder to write correct DTrace scripts and also makes it much harder to debug from logs since you can't assume there's a "request completed" log entry for all requests that did essentially complete.(This was noticed while debugging oxidecomputer/omicron#5111.)
The text was updated successfully, but these errors were encountered: