Skip to content

fix(google): resolve Gemini 3.1 models for all Google provider aliases#56567

Merged
hydro13 merged 1 commit intoopenclaw:mainfrom
hydro13:fix/gemini-31-provider-routing
Mar 28, 2026
Merged

fix(google): resolve Gemini 3.1 models for all Google provider aliases#56567
hydro13 merged 1 commit intoopenclaw:mainfrom
hydro13:fix/gemini-31-provider-routing

Conversation

@hydro13
Copy link
Copy Markdown
Member

@hydro13 hydro13 commented Mar 28, 2026

Summary

  • The forward-compat resolver hardcoded "google" as the provider ID for template lookup, so alias providers (google-vertex, google-gemini-cli) could not find matching templates
  • Pass actual provider ID from runtime context + add templateProviderId fallback for cross-provider template resolution
  • Fix flash-lite prefix ordering: check gemini-3.1-flash-lite before gemini-3.1-flash to prevent misclassification
  • Add regression tests for pro, flash, and flash-lite across provider aliases

Root Cause

resolveGoogle31ForwardCompatModel() in extensions/google/provider-models.ts was called with hardcoded providerId: "google" from extensions/google/index.ts:243. When users configured google-vertex or other aliases, the template lookup failed because no templates existed under that provider ID.

Secondary bug: gemini-3.1-flash-lite starts with gemini-3.1-flash, so without explicit ordering it matched the wrong branch.

Change Type

  • Bug fix

Testing

24 tests pass across 3 test files including new regression coverage for:

  • Gemini 3.1 Pro via google-vertex alias
  • Gemini 3.1 Flash via direct google provider
  • Gemini 3.1 Flash-Lite prefix ordering

Fixes #36111

@openclaw-barnacle openclaw-barnacle Bot added size: S maintainer Maintainer-authored PR labels Mar 28, 2026
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Mar 28, 2026

Greptile Summary

This PR fixes resolveGoogle31ForwardCompatModel so that Google provider aliases (google-vertex, google-antigravity) can resolve Gemini 3.1 models by falling back to google-gemini-cli templates, rather than failing silently because of a hardcoded "google" provider ID. It also corrects a prefix-ordering bug where gemini-3.1-flash-lite was mis-classified as gemini-3.1-flash.

  • Root cause fix (index.ts): Replaces providerId: \"google\" with providerId: ctx.provider and adds templateProviderId: GOOGLE_GEMINI_CLI_PROVIDER_ID as a fallback, so alias providers reach the correct template source.
  • New helper (provider-models.ts): cloneFirstGoogleTemplateModel iterates candidate provider IDs (primary → fallback) and deduplicates them via Set, which is clean and correct.
  • Prefix ordering fix (provider-models.ts): GEMINI_3_1_FLASH_LITE_PREFIX is now checked before GEMINI_3_1_FLASH_PREFIX, preventing misclassification.
  • Flash-lite template list (provider-models.ts): GEMINI_3_1_FLASH_LITE_TEMPLATE_IDS falls back to \"gemini-3-flash-preview\" when no flash-lite-specific template is registered. Flash and flash-lite have different capabilities, so this silent fallback could propagate incorrect metadata (context window, pricing). This path is also not covered by the new tests.
  • google-gemini-cli provider (index.ts:141–142): Left unchanged — its own resolveDynamicModel still calls the function without templateProviderId. This is consistent with it being a standalone provider, but a comment clarifying the intentional omission would help future readers.

Confidence Score: 5/5

Safe to merge; the fix is well-scoped and the two remaining findings are P2 style/coverage concerns that do not block correctness in production.

All identified issues are P2: the flash-lite → flash fallback is a potential metadata inaccuracy without an immediate reproducer, and the google-gemini-cli comment gap is purely cosmetic. The primary regression (alias providers returning undefined for Gemini 3.1 models) is fixed and covered by new tests. No P0/P1 issues found.

extensions/google/provider-models.ts — review GEMINI_3_1_FLASH_LITE_TEMPLATE_IDS fallback to "gemini-3-flash-preview"

Important Files Changed

Filename Overview
extensions/google/provider-models.ts Adds flash-lite prefix/template handling and a new cloneFirstGoogleTemplateModel helper that iterates provider IDs (primary then fallback) for template resolution. Prefix ordering fix (flash-lite before flash) is correct. Minor concern: flash-lite falls back to a flash template when its own template is absent.
extensions/google/index.ts Replaces hardcoded "google" with ctx.provider and adds templateProviderId fallback for the main google provider registration. Correctly resolves templates for hook aliases (google-vertex, google-antigravity). google-gemini-cli provider registration left unchanged (intentional).
extensions/google/provider-models.test.ts New test file covering pro via google-vertex alias, flash via direct google provider, and flash-lite prefix ordering. Covers the primary regression scenarios. Missing coverage for: flash-lite falling back to flash template, and google-antigravity alias.

Comments Outside Diff (1)

  1. extensions/google/index.ts, line 141-142 (link)

    P2 google-gemini-cli provider missing templateProviderId after refactor

    The google provider registration was updated to pass templateProviderId: GOOGLE_GEMINI_CLI_PROVIDER_ID so that alias providers can fall back to google-gemini-cli templates. The google-gemini-cli provider's own resolveDynamicModel was not touched and still calls resolveGoogle31ForwardCompatModel without templateProviderId.

    This is consistent with google-gemini-cli being a standalone provider (not an alias), and the current tests pass because its templates are registered under its own ID. However, if google-gemini-cli ever needs a cross-provider template fallback in the future, no fallback mechanism exists here. A brief comment explaining this intentional omission would help future readers.

    Prompt To Fix With AI
    This is a comment left during a code review.
    Path: extensions/google/index.ts
    Line: 141-142
    
    Comment:
    **`google-gemini-cli` provider missing `templateProviderId` after refactor**
    
    The `google` provider registration was updated to pass `templateProviderId: GOOGLE_GEMINI_CLI_PROVIDER_ID` so that alias providers can fall back to `google-gemini-cli` templates. The `google-gemini-cli` provider's own `resolveDynamicModel` was not touched and still calls `resolveGoogle31ForwardCompatModel` without `templateProviderId`.
    
    This is consistent with `google-gemini-cli` being a standalone provider (not an alias), and the current tests pass because its templates are registered under its own ID. However, if `google-gemini-cli` ever needs a cross-provider template fallback in the future, no fallback mechanism exists here. A brief comment explaining this intentional omission would help future readers.
    
    How can I resolve this? If you propose a fix, please make it concise.

    Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Prompt To Fix All With AI
This is a comment left during a code review.
Path: extensions/google/provider-models.ts
Line: 11-14

Comment:
**Flash-lite falls back to flash template metadata**

`GEMINI_3_1_FLASH_LITE_TEMPLATE_IDS` includes `"gemini-3-flash-preview"` as a fallback when `"gemini-3.1-flash-lite-preview"` isn't found in the registry. Flash and flash-lite have different capabilities (context window, pricing, token limits), so cloning flash metadata for a flash-lite model request would silently produce an incorrect model descriptor.

None of the new tests cover this fallback path (i.e. the case where only `"gemini-3-flash-preview"` is registered but `"gemini-3.1-flash-lite-preview"` is requested). Consider either:
1. Removing the `"gemini-3-flash-preview"` fallback from `GEMINI_3_1_FLASH_LITE_TEMPLATE_IDS` and returning `undefined` when the dedicated template is absent, or
2. Adding a test asserting the expected behaviour when the fallback is exercised, and documenting why borrowing flash properties for flash-lite is acceptable.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/google/index.ts
Line: 141-142

Comment:
**`google-gemini-cli` provider missing `templateProviderId` after refactor**

The `google` provider registration was updated to pass `templateProviderId: GOOGLE_GEMINI_CLI_PROVIDER_ID` so that alias providers can fall back to `google-gemini-cli` templates. The `google-gemini-cli` provider's own `resolveDynamicModel` was not touched and still calls `resolveGoogle31ForwardCompatModel` without `templateProviderId`.

This is consistent with `google-gemini-cli` being a standalone provider (not an alias), and the current tests pass because its templates are registered under its own ID. However, if `google-gemini-cli` ever needs a cross-provider template fallback in the future, no fallback mechanism exists here. A brief comment explaining this intentional omission would help future readers.

How can I resolve this? If you propose a fix, please make it concise.

Reviews (1): Last reviewed commit: "fix(google): resolve Gemini 3.1 models f..." | Re-trigger Greptile

Comment on lines +11 to +14
const GEMINI_3_1_FLASH_LITE_TEMPLATE_IDS = [
"gemini-3.1-flash-lite-preview",
"gemini-3-flash-preview",
] as const;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

P2 Flash-lite falls back to flash template metadata

GEMINI_3_1_FLASH_LITE_TEMPLATE_IDS includes "gemini-3-flash-preview" as a fallback when "gemini-3.1-flash-lite-preview" isn't found in the registry. Flash and flash-lite have different capabilities (context window, pricing, token limits), so cloning flash metadata for a flash-lite model request would silently produce an incorrect model descriptor.

None of the new tests cover this fallback path (i.e. the case where only "gemini-3-flash-preview" is registered but "gemini-3.1-flash-lite-preview" is requested). Consider either:

  1. Removing the "gemini-3-flash-preview" fallback from GEMINI_3_1_FLASH_LITE_TEMPLATE_IDS and returning undefined when the dedicated template is absent, or
  2. Adding a test asserting the expected behaviour when the fallback is exercised, and documenting why borrowing flash properties for flash-lite is acceptable.
Prompt To Fix With AI
This is a comment left during a code review.
Path: extensions/google/provider-models.ts
Line: 11-14

Comment:
**Flash-lite falls back to flash template metadata**

`GEMINI_3_1_FLASH_LITE_TEMPLATE_IDS` includes `"gemini-3-flash-preview"` as a fallback when `"gemini-3.1-flash-lite-preview"` isn't found in the registry. Flash and flash-lite have different capabilities (context window, pricing, token limits), so cloning flash metadata for a flash-lite model request would silently produce an incorrect model descriptor.

None of the new tests cover this fallback path (i.e. the case where only `"gemini-3-flash-preview"` is registered but `"gemini-3.1-flash-lite-preview"` is requested). Consider either:
1. Removing the `"gemini-3-flash-preview"` fallback from `GEMINI_3_1_FLASH_LITE_TEMPLATE_IDS` and returning `undefined` when the dedicated template is absent, or
2. Adding a test asserting the expected behaviour when the fallback is exercised, and documenting why borrowing flash properties for flash-lite is acceptable.

How can I resolve this? If you propose a fix, please make it concise.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 326a068cc0

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread extensions/google/provider-models.ts
The forward-compat resolver hardcoded 'google' as the provider ID for
template lookup, so alias providers (google-vertex, google-gemini-cli)
could not find matching templates. Pass the actual provider ID from the
runtime context and add a templateProviderId fallback for cross-provider
template resolution.

Also fix flash-lite prefix ordering — check 'gemini-3.1-flash-lite'
before 'gemini-3.1-flash' to prevent misclassification.

Add regression tests for pro, flash, and flash-lite across provider
aliases.

Fixes openclaw#36111
@hydro13 hydro13 force-pushed the fix/gemini-31-provider-routing branch from 326a068 to 689b9c7 Compare March 28, 2026 18:58
@hydro13 hydro13 merged commit d1b0f8e into openclaw:main Mar 28, 2026
8 checks passed
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 689b9c7f53

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment on lines +37 to +40
patch: {
...params.patch,
provider: params.providerId,
},
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Preserve transport fields when cloning cross-provider templates

When this helper clones from templateProviderId, it rewrites only provider and keeps the template api/baseUrl, so alias resolution can now return mixed models (fresh evidence: the new test asserts provider: "google-vertex" with api: "google-gemini-cli"). That breaks downstream assumptions keyed on provider ID (for example sanitizeToolsForGoogle only runs for google-gemini-cli), so tool schemas are left unsanitized and Cloud Code requests can fail at runtime on unsupported JSON Schema keywords.

Useful? React with 👍 / 👎.

hydro13 added a commit that referenced this pull request Mar 28, 2026
alexcode-cc pushed a commit to alexcode-cc/clawdbot that referenced this pull request Mar 30, 2026
openclaw#56567)

The forward-compat resolver hardcoded 'google' as the provider ID for
template lookup, so alias providers (google-vertex, google-gemini-cli)
could not find matching templates. Pass the actual provider ID from the
runtime context and add a templateProviderId fallback for cross-provider
template resolution.

Also fix flash-lite prefix ordering — check 'gemini-3.1-flash-lite'
before 'gemini-3.1-flash' to prevent misclassification.

Add regression tests for pro, flash, and flash-lite across provider
aliases.

Fixes openclaw#36111
alexjiang1 pushed a commit to alexjiang1/openclaw that referenced this pull request Mar 31, 2026
openclaw#56567)

The forward-compat resolver hardcoded 'google' as the provider ID for
template lookup, so alias providers (google-vertex, google-gemini-cli)
could not find matching templates. Pass the actual provider ID from the
runtime context and add a templateProviderId fallback for cross-provider
template resolution.

Also fix flash-lite prefix ordering — check 'gemini-3.1-flash-lite'
before 'gemini-3.1-flash' to prevent misclassification.

Add regression tests for pro, flash, and flash-lite across provider
aliases.

Fixes openclaw#36111
pgondhi987 pushed a commit to pgondhi987/openclaw that referenced this pull request Mar 31, 2026
openclaw#56567)

The forward-compat resolver hardcoded 'google' as the provider ID for
template lookup, so alias providers (google-vertex, google-gemini-cli)
could not find matching templates. Pass the actual provider ID from the
runtime context and add a templateProviderId fallback for cross-provider
template resolution.

Also fix flash-lite prefix ordering — check 'gemini-3.1-flash-lite'
before 'gemini-3.1-flash' to prevent misclassification.

Add regression tests for pro, flash, and flash-lite across provider
aliases.

Fixes openclaw#36111
lovewanwan pushed a commit to lovewanwan/openclaw that referenced this pull request Apr 28, 2026
openclaw#56567)

The forward-compat resolver hardcoded 'google' as the provider ID for
template lookup, so alias providers (google-vertex, google-gemini-cli)
could not find matching templates. Pass the actual provider ID from the
runtime context and add a templateProviderId fallback for cross-provider
template resolution.

Also fix flash-lite prefix ordering — check 'gemini-3.1-flash-lite'
before 'gemini-3.1-flash' to prevent misclassification.

Add regression tests for pro, flash, and flash-lite across provider
aliases.

Fixes openclaw#36111
Tardisyuan pushed a commit to Tardisyuan/openclaw that referenced this pull request Apr 30, 2026
openclaw#56567)

The forward-compat resolver hardcoded 'google' as the provider ID for
template lookup, so alias providers (google-vertex, google-gemini-cli)
could not find matching templates. Pass the actual provider ID from the
runtime context and add a templateProviderId fallback for cross-provider
template resolution.

Also fix flash-lite prefix ordering — check 'gemini-3.1-flash-lite'
before 'gemini-3.1-flash' to prevent misclassification.

Add regression tests for pro, flash, and flash-lite across provider
aliases.

Fixes openclaw#36111
ogt-redknie pushed a commit to ogt-redknie/OPENX that referenced this pull request May 2, 2026
openclaw#56567)

The forward-compat resolver hardcoded 'google' as the provider ID for
template lookup, so alias providers (google-vertex, google-gemini-cli)
could not find matching templates. Pass the actual provider ID from the
runtime context and add a templateProviderId fallback for cross-provider
template resolution.

Also fix flash-lite prefix ordering — check 'gemini-3.1-flash-lite'
before 'gemini-3.1-flash' to prevent misclassification.

Add regression tests for pro, flash, and flash-lite across provider
aliases.

Fixes openclaw#36111
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request May 9, 2026
openclaw#56567)

The forward-compat resolver hardcoded 'google' as the provider ID for
template lookup, so alias providers (google-vertex, google-gemini-cli)
could not find matching templates. Pass the actual provider ID from the
runtime context and add a templateProviderId fallback for cross-provider
template resolution.

Also fix flash-lite prefix ordering — check 'gemini-3.1-flash-lite'
before 'gemini-3.1-flash' to prevent misclassification.

Add regression tests for pro, flash, and flash-lite across provider
aliases.

Fixes openclaw#36111
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

maintainer Maintainer-authored PR size: S

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Gemini 3.1 series models not recognized in fallback routing

1 participant