Add a "logprobs" field to correct chat completion when calling a function
The tests have been updated to support the new parameter
This is the root cause of the correction :
`Caused by: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "logprobs" (class org.springframework.ai.mistralai.api.MistralAiApi$ChatCompletion$Choice), not marked as ignorable (3 known properties: "finish_reason", "index", "message"]) at [Source: (org.springframework.util.StreamUtils$NonClosingInputStream); line: 1, column: 362] (through reference chain: org.springframework.ai.mistralai.api.MistralAiApi$ChatCompletion["choices"]->java.util.ArrayList[0]->org.springframework.ai.mistralai.api.MistralAiApi$ChatCompletion$Choice["logprobs"])
com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "logprobs" (class org.springframework.ai.mistralai.api.MistralAiApi$ChatCompletion$Choice), not marked as ignorable (3 known properties: "finish_reason", "index", "message"]) at [Source: (org.springframework.util.StreamUtils$NonClosingInputStream); line: 1, column: 362] (through reference chain: org.springframework.ai.mistralai.api.MistralAiApi$ChatCompletion["choices"]->java.util.ArrayList[0]->org.springframework.ai.mistralai.api.MistralAiApi$ChatCompletion$Choice["logprobs"])`
Comment From: tzolov
@ricken07 thanks for keeping track of the Mistral AI API changes.
For my understanding this does not break any existing functionality? The ITs are passing green as they should. The Spring AI Mistral AI client should be robust enough, not fails if the backend API makes random (not breaking) changes.
Also, could you please create a related GH issue to make those type of API changes more visible.
Comment From: ricken07
@tzolov it's true for current ITs. I think it impacts MistralAiAPi when calling the function, I'll look for an IT test case to reproduce the exception before create a related GH issue, because in my case, I receive in response a JSON object with the field "logprobs".
Comment From: tzolov
@ricken07 would appreciate this. Looks like more than one thing is going on. The mapping error causes the stream to not be classed. If you find a what to reproduce it it would help to straighten our streaming impl. I guess we need to set a doOnError ...
Comment From: tzolov
@ricken07 any luck in reproducing the issue?
Comment From: ricken07
@tzolov I still haven't found a way to reproduce the issue.
Comment From: tzolov
Ok , will review/merge it without test.
Comment From: tzolov
@ricken07 have you run successfully the integration tests?
Comment From: ricken07
@tzolov yes tests are green
Comment From: tzolov
I had to add this patch first: 7e03a15cf5ce4fbdfcf219fbfed84514201d4d67
Something changed in the streaming function response. It splits the tool_calls response in 2 messages. First with the role and the second with the tool_calls but empty role.
Currently we a looking for the tool_calls non-empty field to detect function calls .So the above fix adds the missing assistant role.
Comment From: tzolov
Rebased and merged at 5f9ecdd899761974e77114f7584610aa803a3e97