[BUG] GEMINI MODELS HANDLING FAILS

[EdizAnil]

Problem (one or two sentences)

Gemini models started to fail after I update the extension.

Date/time: 2026-04-02T13:35:52.871Z
Extension version: 3.51.1
Provider: vertex
Model: gemini-3.1-pro-preview

Unexpected API Response: The language model did not provide any assistant messages. This may indicate an issue with the API or the model's output.

Date/time: 2026-04-02T13:37:29.751Z
Extension version: 3.51.1
Provider: vertex
Model: gemini-2.5-flash

Unexpected API Response: The language model did not provide any assistant messages. This may indicate an issue with the API or the model's output.

Context (who is affected and when)

Happens when a new request sent to any gemini models over gcp vertex ai

Reproduction steps

Environment setup: Windows 11, vscode v1.107.1, Extension version: 3.51.1

Expected result

Gemini api handling to be fixed

Actual result

gemini api handling fixed

Variations tried (optional)

No response

App Version

3.51.1

API Provider (optional)

Google Vertex AI

Model Used (optional)

gemini-3.1-pro-preview

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

The root cause is that when the Gemini API returns an empty or blocked response (e.g., due to safety filters, recitation checks, max tokens, or reasoning-only output), the handler silently produces no output. This causes Task.ts to fall into the generic "The language model did not provide any assistant messages" error path, giving no useful information about what actually went wrong.

Two changes are needed:

1. Surface non-STOP finishReason in src/api/providers/gemini.ts

After the stream completes, if the Gemini API returned a non-STOP finishReason (such as SAFETY, RECITATION, MAX_TOKENS, PROHIBITED_CONTENT) and no content was produced, throw a descriptive error with the actual finish reason. Currently this is swallowed silently. This change goes after the responseId capture (around line 305) and before grounding metadata processing.

2. Handle reasoning-only responses in src/core/task/Task.ts

When a thinking/reasoning model (like gemini-3.1-pro-preview) returns only reasoning content without actionable text or tool calls, the current code treats this as a complete failure. Instead, we should detect reasoning-only responses (reasoning content was produced but no text/tool output) and treat them as a transient issue that can be silently retried without incrementing the consecutive failure counter.

These fixes will ensure users see the actual API error reason (e.g., "finishReason: SAFETY") instead of the opaque "no assistant messages" error, and that reasoning-only responses get a free retry.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[EdizAnil]

@roomote I approve the plan, proceed with the implementation.

[roomote-v0]

I've seen the approval and will proceed with the implementation now. I'll open a draft PR to share progress shortly.

[roomote-v0]

Opened PR #12046 with my attempt at addressing this. The changes surface the actual Gemini finishReason (SAFETY, RECITATION, etc.) instead of the generic "no assistant messages" error, and handle reasoning-only responses from thinking models. Feedback welcome!