fix ResultsFormat error when loading old sessions

[zanesq]

Follow up for #6094

Summary: Session Loading Backward Compatibility Fix

Problem

Users reported an error when loading/chatting after upgrading the desktop app: stream error: failed to read session: data did not match any variant of untagged enum ResultFormat at line 1 column 136

Root Cause

The issue was a schema mismatch between old and new session data formats:

• Old format (ToolCall): arguments: serde_json::Value (could be any JSON type)
• New format (CallToolRequestParam): arguments: Option<JsonObject> (must be an object or null)

When deserializing old sessions where arguments was a string, array, or number, the new deserialization logic failed because it couldn't match any variant of the ResultFormat enum.

Solution

Modified crates/goose/src/conversation/tool_result_serde.rs to handle legacy ToolCall format:

1. Added a LegacyToolCall struct to accept arguments: serde_json::Value
2. Updated the deserialize function to include a LegacySuccess variant for backward compatibility
3. Added conversion logic in LegacyToolCall::into_call_tool_request_param():
   • JSON object → used directly as Some(map)
   • null → converted to None
   • Other types (string, number, array, boolean) → wrapped in {"value": <original>}

Files Changed

crates/goose/src/conversation/tool_result_serde.rs

• Added LegacyToolCall struct with arguments: serde_json::Value
• Added into_call_tool_request_param() conversion method
• Modified deserialize function to handle both new and legacy formats

crates/goose/src/conversation/message.rs

• Added 5 new unit tests covering legacy argument types:
  • test_legacy_tool_request_with_value_arguments (string)
  • test_legacy_tool_request_with_array_arguments
  • test_legacy_tool_request_with_number_arguments
  • test_legacy_tool_request_with_null_arguments
  • test_legacy_tool_request_with_object_arguments

Verification

• ✅ Code compiles successfully
• ✅ All 27 message tests pass
• ✅ Clippy checks pass
• ✅ Code formatted with cargo fmt

[DOsinga]

these tests are rather repetitive - if you wanted to do this, turn them into parameterized tests that only have the difference between the cases rather than repeating yourself.

but we should maybe think one deeper on how we avoid breaking this in the future - it happened before when we change the message format. adding tests like this is just very specifically going to test for this, doesn't seem that likely that we'll catch future issues.

wouldn't it be better to just check in a bunch of historic conversations and verify that we can load them?

[DOsinga]

I think it would be better to remove the comments here and also not call it just legacy; surely we'll have more changes to formats coming up, representing in the name what's going on here would be better. LegacyToolCallWithValue? longer names beats comments here for sure.

[DOsinga]

same here; New is not going stay that way