-
Notifications
You must be signed in to change notification settings - Fork 451
Description
Describe the bug
CreateTaskResult and GetTaskInfoResult have near-identical structures:
rust-sdk/crates/rmcp/src/model/task.rs
Lines 65 to 67 in 32a68aa
| pub struct CreateTaskResult { | |
| pub task: Task, | |
| } |
rust-sdk/crates/rmcp/src/model.rs
Lines 2050 to 2053 in 32a68aa
| pub struct GetTaskInfoResult { | |
| #[serde(skip_serializing_if = "Option::is_none")] | |
| pub task: Option<crate::model::Task>, | |
| } |
This causes tasks/get responses to be deserialized as CreateTaskResult instead of GetTaskInfoResult.
To Reproduce
Steps to reproduce the behavior:
- Send the
tasks/getrequest.
let client = // Client initialization logic.
let server_result: ServerResult = client
.send_request(ClientRequest::GetTaskInfoRequest(GetTaskInfoRequest {
method: GetTaskInfoMethod,
params: GetTaskInfoParams {
meta: None,
task_id: task_id.clone(),
},
extensions: Extensions::default(),
}))
.await?; // `server_result` is `ServerResult::CreateTaskResult`Expected behavior
server_result should be ServerResult::GetTaskInfoResult
Additional context
I am using the latest commit (32a68aa) because the published version 0.14.0 does not include the enum-variant reordering fix.
rmcp = { git = "https://github.com/modelcontextprotocol/rust-sdk", features = ["macros", "client", "rmcp/transport-streamable-http-client-reqwest"] }One possible solution would be to simply do:
match server_result {
ServerResult::CreateTaskResult(task_info) => GetTaskInfoResult {
task: Some(task_info.task),
},
ServerResult::GetTaskInfoResult(task_info) => task_info,
_ => return Err(ServiceError::UnexpectedResponse),
};But this feels very unintuitive.
Personally, I am not a huge fan of how a single enum is used for all possible requests/responses. I do not know how this could be fixed properly without changing that.