取消流程
当一方想要取消进行中的请求时,它会发送一个notifications/cancelled 通知,包含:
- 要取消的请求 ID
- 一个可选的原因字符串,可用于记录或显示
行为要求
- 取消通知必须仅引用以下请求:
- 之前在同一方向发出的
- 被认为仍在进行中的
initialize请求不得被客户端取消- 对于 任务增强请求,必须使用
tasks/cancel请求而不是notifications/cancelled通知。任务拥有自己专用的取消机制,会返回最终任务状态。 - 取消通知的接收者应该:
- 停止处理被取消的请求
- 释放相关资源
- 不为被取消的请求发送响应
- 接收者可以忽略取消通知,如果:
- 引用的请求未知
- 处理已经完成
- 请求无法被取消
- 取消通知的发送者应该忽略随后到达的对该请求的任何响应
时序考虑
由于网络延迟,取消通知可能在请求处理完成后到达,甚至可能在响应已经发送之后到达。 双方必须妥善处理这些竞态条件:实现说明
- 双方应该记录取消原因以便调试
- 应用程序 UI 应该在请求取消时予以指示
错误处理
无效的取消通知应该被忽略:- 未知的请求 ID
- 已完成的请求
- 格式错误的通知