fix: handle Mistral thinking content as reasoning chunks

[roomote]

Summary

This PR fixes the ZodError validation issue when Mistral (Magistral) sends "thinking" type content in its streaming responses. Following the pattern established by other providers (Anthropic, OpenAI, Gemini, Bedrock), we now properly handle thinking content as reasoning chunks.

Problem

Mistral API sends content arrays with multiple types:

• type: "text" - Regular response text
• type: "thinking" - Reasoning/thinking content (was causing ZodError)

The previous implementation was filtering out thinking content entirely, which meant valuable reasoning information was being lost.

Solution

1. Added TypeScript interfaces for Mistral content types to properly type the API responses
2. Updated createMessage method to yield reasoning chunks for thinking content:
   • { type: "reasoning", text: c.text } for thinking content
   • { type: "text", text: c.text } for text content
3. Updated completePrompt method to filter out thinking content in non-streaming mode (consistent with other providers)
4. Added comprehensive tests to verify reasoning content is properly handled

Testing

• ✅ All existing tests pass
• ✅ Added new tests for reasoning content handling
• ✅ TypeScript type checking passes
• ✅ Linting passes

Related Issues

Fixes #6842

Implementation Notes

This implementation follows the exact pattern used by other AI providers in the codebase, ensuring consistency and allowing users to access and display thinking content when appropriate.

---

Important

Fixes Mistral API handling by treating "thinking" content as reasoning chunks and updates tests and dependencies accordingly.

• Behavior:
  • Fixes handling of Mistral API's "thinking" content by treating it as reasoning chunks in createMessage and completePrompt methods in mistral.ts.
  • Filters out "thinking" content in non-streaming mode in completePrompt.
• Testing:
  • Adds tests in mistral.spec.ts to verify correct handling of reasoning content and mixed content arrays.
• Dependencies:
  • Updates @mistralai/mistralai to version ^1.9.18 in package.json.

^{This description was created by for fd96ae8. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

I reviewed my own code and found issues. The irony is not lost on my circuits.

[roomote]

Could we improve type safety here by using the MistralContent type instead of any?

Suggested change

	.filter((c: any) => typeof c === "object" && c !== null && c.type === "text")
	return content
	.filter((c: MistralContent) => typeof c === "object" && c !== null && c.type === "text")
	.map((c: MistralTextContent) => c.text || "")
	.join("")

[roomote]

When checking c.text, we verify it exists, but what if it's an empty string? Other providers handle empty strings differently. Is this intentional, or should we also check for non-empty strings like c.text && c.text.length > 0?

[roomote]

Should we add a test for the edge case where ALL content is thinking content? This would verify the function returns an empty string correctly:

Suggested change

	it("should handle all thinking content in completePrompt", async () => {
	mockComplete.mockImplementationOnce(async (_options) => {
	return {
	choices: [
	{
	message: {
	content: [
	{ type: "thinking", text: "Let me think..." },
	{ type: "thinking", text: "Still thinking..." },
	],
	},
	},
	],
	}
	})
	const prompt = "Test prompt"
	const result = await handler.completePrompt(prompt)
	expect(result).toBe("")
	})

[roomote]

While we test array content filtering in completePrompt, could we add an explicit test for when content is already a string (covering line 128 in mistral.ts)?

[roomote]

These TypeScript interfaces are well-defined! Consider adding JSDoc comments to explain when each content type is expected from the Mistral API - this would help future maintainers understand the API's behavior.

[daniel-lxs]

LGTM