Skip to content

Skip empty Gemini thought parts instead of emitting empty reasoning#543

Open
PratikDhanave wants to merge 3 commits into
microsoft:mainfrom
PratikDhanave:fix-gemini-empty-thought
Open

Skip empty Gemini thought parts instead of emitting empty reasoning#543
PratikDhanave wants to merge 3 commits into
microsoft:mainfrom
PratikDhanave:fix-gemini-empty-thought

Conversation

@PratikDhanave

Copy link
Copy Markdown
Contributor

Problem

In buildResponsePart (provider/geminiprovider/agent.go), a response part with Thought=true is appended as TextReasoningContent unconditionally, while the sibling text branch guards on part.Text != "":

if part.Thought {
    // ... always appends TextReasoningContent
} else if part.Text != "" {
    // only appends TextContent when non-empty
}

So a thought part carrying neither thinking text nor a ThoughtSignature produces an empty, information-free TextReasoningContent{Text:"", ProtectedData:""} in the response message.

Fix

Guard the thought branch on part.Text != "" || len(part.ThoughtSignature) > 0, mirroring the text guard. A signature-only thought (empty text, non-empty signature) is still emitted so the signature round-trips via ProtectedData in multi-turn requests — only the fully-empty thought part is skipped.

Test

TestResponseWithEmptyThoughtPartOmitted (black-box, in agent_test.go) returns a candidate with an empty {"thought": true} part alongside a normal text part, and asserts no TextReasoningContent is produced. Fails on main (empty reasoning content emitted), passes with the fix. The existing thinking-content and thought-signature tests are unchanged.

buildResponsePart appended a TextReasoningContent for every part with
Thought=true, unconditionally — unlike the text branch, which guards on
part.Text != "". A thought part carrying neither thinking text nor a
ThoughtSignature therefore produced an empty, information-free
TextReasoningContent{Text:"", ProtectedData:""} in the response.

Guard the thought branch on part.Text != "" || len(part.ThoughtSignature) > 0,
mirroring the text guard. A signature-only thought is still emitted so its
signature round-trips via ProtectedData in multi-turn requests; only the
fully-empty thought part is skipped.
Copilot AI review requested due to automatic review settings July 18, 2026 03:21
@PratikDhanave
PratikDhanave requested a review from a team as a code owner July 18, 2026 03:21

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the Gemini provider’s response-part translation so that “thought” parts that carry no useful information (no thinking text and no thought signature) are omitted rather than being converted into an empty TextReasoningContent, aligning behavior with the existing “skip empty text parts” logic.

Changes:

  • Skip emitting TextReasoningContent for thought=true parts when both Text and ThoughtSignature are empty.
  • Add a black-box test covering an empty thought-only part in the response.
  • Minor formatting change to a test call site for RunText(...).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
provider/geminiprovider/agent.go Adds a guard to avoid appending empty reasoning content for fully-empty thought parts while still preserving signature-only thoughts.
provider/geminiprovider/agent_test.go Adds a regression test for omitting empty thought parts and includes a minor formatting adjustment in an existing test.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +796 to +803
for _, msg := range result.Messages {
for _, c := range msg.Contents {
if rc, ok := c.(*message.TextReasoningContent); ok {
t.Errorf("expected no reasoning content for an empty thought part, got Text=%q ProtectedData=%q", rc.Text, rc.ProtectedData)
}
}
}
}
Address review feedback: the test asserted only the absence of reasoning
content, so it would also pass if the provider dropped all response parts.
Also assert the normal text part is still emitted.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants