pub struct RequestCancellationHandle { /* private fields */ }Expand description
Explicit cancellation control for one outgoing request.
Obtain this handle from PreparedRequest::cancellation_handle or
SentRequest::cancellation_handle before consuming the request. It retains
neither the response consumer nor application callback, so cancellation can
be requested without discarding the eventual response. It does not keep the
connection driver or response consumer alive, or abort local callback work.
Clones share the request’s cancellation state with SentRequest::cancel,
forwarded cancellation, and request-drop automatic cancellation. At most one
cancellation notification is attempted, with the original peer and proxy
wrapping. Dropping this handle neither cancels the request nor disables its
automatic cancellation.
Cancellation before publication is a no-op and is not remembered for later publication. A call racing publication may also be a no-op; call after the publishing method returns to target a pending request. Once the SDK routes a response or fails the request, subsequent cancellation calls are no-ops, even if its callback has not yet run. Detaching the request suppresses only automatic cancellation; retained handles can still explicitly cancel it.
This controls outgoing requests, unlike RequestCancellation, which
observes a peer’s cancellation of an incoming request.
Implementations§
Source§impl RequestCancellationHandle
impl RequestCancellationHandle
Sourcepub fn cancel(&self) -> Result<(), Error>
pub fn cancel(&self) -> Result<(), Error>
Ask the peer to cancel this request without discarding its response.
Cancellation is cooperative: the peer may respond normally or with a
cancellation error. Repeated calls, including calls through other clones
or the original request, return Ok(()) without sending another
notification. Calls before publication or after settlement are no-ops.
An attempt begun before settlement may still enqueue afterward.
Ok(()) means this call encountered no immediate error, not that a
notification was sent or the peer stopped work. This method does not
wait for transmission or acknowledgment.
§Errors
Only the call that attempts to send reports serialization or enqueue failure. A failed send is not retried by later cancellation calls.