Skip to content

tasks/get response deserialized as CreateTaskResult instead of GetTaskInfoResult #637

@coinmoles

Description

@coinmoles

Describe the bug
CreateTaskResult and GetTaskInfoResult have near-identical structures:

pub struct CreateTaskResult {
pub task: Task,
}

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:

  1. Send the tasks/get request.
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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions