[Platform][Gemini] Fix choice conversion logic for executableCode and codeExecutionResult

[pentiminax]

Q	A
Bug fix?	yes
New feature?	no
Docs?	no
Issues	Fix #422
License	MIT

This PR fixes a crash in the Gemini ResultConverter when handling responses that only contained executableCode and codeExecutionResult parts.

Before:

• RuntimeException: Unsupported finish reason "STOP"

After:

• Proper conversion into a TextResult containing formatted code blocks and the last successful OUTCOME_OK output.
• No more exceptions for valid Gemini responses.

What’s Changed

• Enhanced choice conversion logic in ResultConverter::convertChoice():
• Single part → keep legacy behavior (functionCall, text, or one code/output part).
• Multiple parts → aggregate:
• executableCode → Markdown code blocks.
• codeExecutionResult (OUTCOME_OK) → output block.
• Parts flagged as thought: true are ignored for text/code, but their successful execution results are preserved.

New unit tests:

• Covers the failing payload where all parts were marked thought: true.
• Ensures the result is a readable TextResult instead of an exception.

Why

• Prevents crashes when Gemini outputs reasoning steps as thought: true.
• Keeps only useful information (code + last valid output).
• Maintains backward compatibility for simpler responses.

Impact

• No BC breaks — existing behavior for single-part responses unchanged.
• Improved UX — users now see clean Markdown code + output instead of runtime errors.

[OskarStark]

friendly ping @valtzu

[Copilot]

Pull Request Overview

This PR fixes a crash in the Gemini ResultConverter when handling responses containing only executableCode and codeExecutionResult parts, particularly when all parts are marked as thought: true. The fix prevents RuntimeException: "Unsupported finish reason STOP" by implementing proper aggregation logic for multi-part responses.

• Enhanced choice conversion logic to handle both single-part (legacy) and multi-part responses
• Added aggregation of executable code into formatted content and preservation of successful execution results
• Comprehensive test coverage for the previously failing scenario with thought-flagged parts

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/platform/src/Bridge/Gemini/Gemini/ResultConverter.php	Enhanced convertChoice method to aggregate multiple parts containing executable code and execution results
src/platform/tests/Bridge/Gemini/CodeExecution/ResultConverterTest.php	Added test case covering the crash scenario with thought-flagged parts containing code execution

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[OskarStark]

So this response contains 2 failed and one OK?

[pentiminax]

Yes, this response matches the requested prompt:

'Count how many times each word appears in this text using the Python code execution tool:
"Symfony est un framework PHP. Symfony est utilisé dans de nombreux projets. PHP est un langage puissant."
Display the result as a dictionary sorted by frequency, then explain the result.'

It seems Gemini iteratively fixed its code until it executed correctly.

[OskarStark]

so would be good to have a fixture (and test) for failed, too

[pentiminax]

Finally, I removed the isSuccessfulCodeExecution condition, we want to display all the LLM’s thoughts to the user, right?"

[pentiminax]

For information: https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/code-execution-api

[valtzu]

First of all, thanks for working on this – when the server_tools were implemented, I only ever tested google_search and url_context.

In my opinion the output should not contain the generated & executed code by default, since the last message/part is a human readable message which already contains the answer to the asked question.

The code_execution is a server tool, like google_search or url_context, and those don't show up in the output either – even though f.e. search results / "sources" are available as "grounding" in the response.

---

If I'm building a customer-facing chat bot which should be able to answer to Calculate 20th fibonacci number. Then find the nearest palindrome to it. (an example from the code_execution docs), I don't think the customer should see the python code.

---

Somewhere we have this feature: keepToolMessages. Maybe we could even use that, or add a new one, like keepServerToolParts to control if those will be included or not 🤔

[valtzu]

When I tried it via the API, after codeExecutionResult.outcome: "OUTCOME_OK" there is a normal text part, i.e.

          {
            "text": "The 20th Fibonacci number is 6765.\n\nThe nearest palindrome to 6765 is 6776."
          }

Did you not get it in the response? If you did, let's add it to the fixture?

[pentiminax]

It's weird, I never saw this part before, but you right I have it in API response, I will take this part into account.
I think text is not in the response when we have parts with thoughts key.

[pentiminax]

First of all, thanks for working on this – when the server_tools were implemented, I only ever tested google_search and url_context.

In my opinion the output should not contain the generated & executed code by default, since the last message/part is a human readable message which already contains the answer to the asked question.

The code_execution is a server tool, like google_search or url_context, and those don't show up in the output either – even though f.e. search results / "sources" are available as "grounding" in the response.

If I'm building a customer-facing chat bot which should be able to answer to Calculate 20th fibonacci number. Then find the nearest palindrome to it. (an example from the code_execution docs), I don't think the customer should see the python code.

Somewhere we have this feature: keepToolMessages. Maybe we could even use that, or add a new one, like keepServerToolParts to control if those will be included or not 🤔

Thanks a lot for clarifying! I see your point now. Since code_execution is indeed just another server tool like google_search or url_context, it makes sense to treat it consistently and not expose the raw code by default. The final human-readable message is usually enough for the end user, while the tool details can stay in the background.

I like the idea of making this configurable.

[OskarStark]

The rebase looks wrong

[pentiminax]

At the moment the code iterates through the contentParts array and looks for a successful code execution marker.

• Once a successful execution is detected, the flag $successfulCodeExecutionDetected is set to true.
• From that point onward, it concatenates any following text parts into the $content string.
• If any text was collected, it returns a TextResult containing that aggregated content.
• If no content was collected, it throws a RuntimeException("Code execution failed.").

[OskarStark]

Only one minor, afterwards good to merge. Thanks

[OskarStark]

Thanks for fixing this bug @pentiminax.

[pentiminax]

Thanks for reviewing @OskarStark.
I think we will have the same problem with Vertex bridge since it's Google models?

[OskarStark]

Yes, can you have a look?