pub trait CancellationHandler:
Send
+ Sync
+ Debug {
// Required method
fn handle_cancellation<'life0, 'async_trait>(
&'life0 self,
notification: CancelledNotification,
) -> Pin<Box<dyn Future<Output = HandlerResult<()>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait;
}Expand description
Cancellation handler for processing cancellation notifications
Per MCP 2025-06-18 specification, notifications/cancelled can be sent by
either side to indicate cancellation of a previously-issued request.
When the server sends a cancellation notification, it indicates that a request the client sent is being cancelled and the result will be unused. The client SHOULD cease any associated processing.
§MCP Specification
From the MCP spec:
- “The request SHOULD still be in-flight, but due to communication latency, it is always possible that this notification MAY arrive after the request has already finished.”
- “A client MUST NOT attempt to cancel its
initializerequest.”
§Examples
use turbomcp_client::handlers::{CancellationHandler, CancelledNotification, HandlerResult};
use async_trait::async_trait;
#[derive(Debug)]
struct MyCancellationHandler;
#[async_trait]
impl CancellationHandler for MyCancellationHandler {
async fn handle_cancellation(&self, notification: CancelledNotification) -> HandlerResult<()> {
println!("Request {} was cancelled", notification.request_id);
if let Some(reason) = ¬ification.reason {
println!("Reason: {}", reason);
}
// In a real implementation:
// - Look up the in-flight request by notification.request_id
// - Signal cancellation (e.g., via CancellationToken)
// - Clean up any resources
Ok(())
}
}