fix(antigravity): always include text field in thought parts to prevent Google 500

[sususu98]

Summary

When Claude sends redacted thinking with empty text ("thinking": ""), the translator omits the "text" field from thought parts. Google Antigravity API requires this field, causing 500 "Unknown Error" responses.

Root Cause

In antigravity_claude_request.go, the thought block construction had a conditional:

if thinkingText != "" {
    partJSON, _ = sjson.SetBytes(partJSON, "text", thinkingText)
}

This produces {"thought": true, "thoughtSignature": "..."} without a "text" field when thinking text is empty (redacted thinking). Google's API fails to parse this and returns a generic 500.

Fix

Always include the "text" field, even when empty:

partJSON, _ = sjson.SetBytes(partJSON, "text", thinkingText)

Verification

Analyzed 270 log files (173 error + 97 success):

	Empty thought (no text)	Thought with text	No thought
500 Unknown Error	129	0	0
200 Success	0	61	35

After deploying the fix: 0 new "Unknown Error" 500s observed, confirming the root cause.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical issue where the Google Antigravity API returned 500 'Unknown Error' responses. The problem stemmed from the API's strict requirement for a 'text' field within thought parts, which was previously omitted when Claude sent redacted thinking with empty text. The change ensures this field is consistently present, thereby stabilizing API interactions and preventing these errors.

Highlights

• Google Antigravity API 500 Error Resolution: Previously, when Claude sent redacted thinking with empty text, the 'text' field was omitted from thought parts. Google's Antigravity API requires this field, leading to 500 'Unknown Error' responses.
• Ensured 'text' Field Presence: The fix ensures that the 'text' field is always included in thought parts, even when the thinking text is empty, satisfying Google Antigravity API requirements and preventing 500 errors.
• Verification Confirmed Effectiveness: Analysis of logs showed 129 'Unknown Error' 500s related to empty thought parts before the fix, and zero new 500s were observed after deployment, confirming the resolution.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request addresses a 500 error from the Google Antigravity API by ensuring the text field is always included in thought parts, even when the thinking text is empty. The change removes the conditional that previously omitted the field for empty text. The fix is consistent with the problem description and correctly resolves the issue.

[xkonjin]

Code Review

Summary: Always includes the text field in thought parts sent to Google Antigravity API, even when empty. Prevents Google 500 errors from missing required fields.

Issues Found

🐛 Indentation regression (blocking)
The entire thinking-block handling section (lines ~107-160) has been re-indented from tabs to mixed spaces, breaking the Go formatting convention used throughout this file. The functional change is a single-line removal of the conditional:

// Before: text was conditional
if thinkingText != "" {
    partJSON, _ = sjson.SetBytes(partJSON, "text", thinkingText)
}
// After: text is always set (the actual fix)
partJSON, _ = sjson.SetBytes(partJSON, "text", thinkingText)

The fix itself is correct and minimal, but the surrounding whitespace changes make the diff 5x larger than needed and introduce inconsistent indentation (spaces where the rest of the file uses tabs). Please run gofmt or goimports on this file and split the formatting into a separate commit, or revert the whitespace-only changes.

✅ Logic is sound

• Unconditionally setting text (even to "") is the right fix for the Google API requirement.
• No behavioral change to signature validation or unsigned-block dropping.

Verdict

The one-line fix is correct and addresses a real production issue. The whitespace noise should be cleaned up before merge to keep blame/history useful.