.Net: Bug: Gemini Responses Don't Deserialize (calling functions)

[DevEnable]

Describe the bug
This seems to be an issue which has only started to occur in the last 12-24 hours. Previously the connector was working fine. No changes have been made to the code since. (Apart from updating to the latest version of SK to try and resolve this issue)

I'm guessing the issue is because Google has changed their API contract in some way

To Reproduce

• Create an application that uses the Google connector and either Flash or Gemini 2.5 Pro that calls a function (auto)
• When SK / the LLM tries to call the function it will fail to deserialise. Running a debugger across it I can see the issue is when it is deserialising the GeminiPart and after deserialising the object it calls IsValid. This fails as ALL of the parts are null. Here is an obfusciated response I can see from Google using the exception's Data dictionary "ResponseData":

{
"candidates": [
{
"content": {
"parts": [
{
"thought": true,
"thoughtSignature": "xyz=="
},
{
"functionCall": {
"name": "MyPlugin_my_function",
"args": {
"requests": [
{
"MyArg": "MyValue"
}
]
}
}
}
],
"role": "model"
},
"finishReason": "STOP",
"index": 0
}
],
...
}

As you can se the "functionCall" is present. I'm not sure what has changed as I've not retrieved a prior working version.

Expected behavior
The response from Google should deserialise.

Platform

• Language: C#
• Source: Microsoft.SemanticKernel.Connectors.Google 1.54.0-alpha (connector, other SK libraries are 1.54.0)
• AI model: gemini-2.5-flash-preview-05-20, gemini-2.5-pro-preview-05-06.

I just tried gemini-2.5-pro-preview-03-25 and it also has the same problem.

• IDE: Jetbrains Rider
• OS: Mac

[DevEnable]

Could the issue be related to this? https://github.com/googleapis/python-genai/releases. (See Adding thought_signature field to the Part to store the signature for thoughts. (303f906))

[rogerbarreto]

@DevEnable This issue seems related to C#, current under investigation. Thanks for the heads up!

[DevEnable]

@DevEnable This issue seems related to C#, current under investigation. Thanks for the heads up!

@rogerbarreto you are probably all across this but looking at the GeminiPart and the recent commit from Google's Python SDK it looks like they've introduced a new "thought" part and that is what is breaking the deserialisation / logic.

It hasn't impacted me too badly as I just switched to the Azure Open AI LLMs (yet another great benefit of SK) but each LLM treats prompts differently so it hasn't been a like for like.

I'm not in production at the moment so it's not a big deal. But my concern is later down the line if Google were to do something similar again and introduce another part type. If I were to wait for a fix (which may take days) my platform would seriously impacted (unless I switched LLMs again or tried to figure out the code and created my own fork with a fix) as currently all prompts which rely on function calls (most of mine) would fail.

Without trying to over-engineer a solution, but to provide some future-proofing. Would it be possible to introduce some sort of configuration variable that instructed the deserialisation logic to ignore any parts it doesn't recognise? Turned off by default so we aren't silently ignoring potential issues, but with the option to turn it on should something like this happen until SK can catch up? It would be a lot less stressful for everyone involved 😃, and help to reduce one of the drawbacks of not directly using Google's SDK / APIs.

It could be a bool or a string[] (of part names to ignore).

If not and I am massively blowing out the scope, then I'll make sure to tag your PR so I can hopefully quickly fix it again in the future should Google make a similar set of changes.

[rogerbarreto]

@DevEnable

Without trying to over-engineer a solution, but to provide some future-proofing. Would it be possible to introduce some sort of configuration variable that instructed the deserialisation logic to ignore any parts it doesn't recognise? Turned off by default so we aren't silently ignoring potential issues, but with the option to turn it on should something like this happen until SK can catch up? It would be a lot less stressful for everyone involved 😃, and help to reduce one of the drawbacks of not directly using Google's SDK / APIs.

For scenarios like this one approach I would use is introduce a custom httpClient with a httpHandler into the extensions so you can intercept all the request bodies as well as the responses and make the adjustments that conform to the current implementation.

For example, removing the thinking parameters / parts, or moving those as new parts that conform to current implementation.

Same for the out going request, if the contract in the API changes and don't accept some field or expect an extra field you can inject your custom logic ahead of time.

Something on those lines:

semantic-kernel/dotnet/samples/Concepts/ChatCompletion/OpenAI_CustomClient.cs

Line 66 in 2f84e5d

private sealed class MyCustomClientHttpHandler(ITestOutputHelper output) : HttpClientHandler