Update Gemini 3.1 Pro Integration#584
Conversation
- Update model identifier to `gemini-3.1-pro-preview` in `lib/utils/index.ts` - Update model selection UI to display "Gemini 3.1 Pro" - Add backward compatibility for users with "Gemini 3" selected - Rename and update documentation to `GEMINI_3.1_PRO_INTEGRATION.md` - Update `.env.local.example` with 3.1 Pro references Co-authored-by: ngoiyaeric <115367894+ngoiyaeric@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
Review Summary by QodoUpdate Gemini integration to 3.1 Pro with backward compatibility
WalkthroughsDescription• Update Gemini model from 3 Pro to 3.1 Pro across codebase • Add backward compatibility for existing "Gemini 3" model selection • Update model identifier to gemini-3.1-pro-preview in API calls • Refresh documentation and environment configuration files Diagramflowchart LR
A["getModel function"] -->|"Update model ID"| B["gemini-3.1-pro-preview"]
A -->|"Add case for"| C["Gemini 3.1 Pro"]
C -->|"Backward compat"| D["Gemini 3 case"]
E["Documentation"] -->|"Rename & update"| F["GEMINI_3.1_PRO_INTEGRATION.md"]
G[".env.local.example"] -->|"Update references"| H["Gemini 3.1 Pro"]
I["Model Selection UI"] -->|"Update display"| J["Gemini 3.1 Pro badge"]
File Changes1. lib/utils/index.ts
|
Code Review by Qodo
1. Legacy model not migrated
|
|
Warning Rate limit exceeded
To continue reviewing without waiting, purchase usage credits in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
WalkthroughThe PR adds support for Gemini 3.1 Pro as an AI provider option. It updates environment variable documentation, implements model selection logic with API key configuration, adds the new model to the UI model picker, and provides integration documentation with technical details and priority ordering. ChangesGemini 3.1 Pro Provider Integration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related issues
Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| id: "Gemini 3.1 Pro", | ||
| name: "Gemini 3.1 Pro", | ||
| description: "Google's latest reasoning model, excelling at multimodal understanding and complex agentic tasks.", | ||
| icon: Sparkles, | ||
| badge: "Multimodal", | ||
| badge: "Advanced", | ||
| badgeVariant: "outline" as const, | ||
| }, |
There was a problem hiding this comment.
1. Legacy model not migrated 🐞 Bug ≡ Correctness
Existing users with a persisted selectedModel value of "Gemini 3" will no longer have a matching option in the Model Selection UI after the option was renamed to "Gemini 3.1 Pro", so the UI renders as unselected and the stored value is not upgraded. This contradicts the intended automatic upgrade behavior and leaves legacy values in the DB indefinitely.
Agent Prompt
### Issue description
Users may still have `users.selectedModel = "Gemini 3"` stored in the database, but the Settings UI no longer offers an option with that value (it now offers only `"Gemini 3.1 Pro"`). This causes the Settings Model Selection UI to render with no option selected, and the persisted value is never upgraded.
### Issue Context
- The ModelSelectionForm’s Select/RadioGroup options are driven by a local `models` array.
- Settings initializes `selectedModel` directly from `getSelectedModel()`.
- `getModel()` has a runtime fallback for legacy "Gemini 3", but this does not migrate the stored value nor fix the Settings UI.
### Fix approach
Implement a one-time migration/mapping from `"Gemini 3"` → `"Gemini 3.1 Pro"` when reading or when initializing the form, and optionally persist the migrated value.
Good options:
1. **Server-side (preferred):** In `getSelectedModel()`, if the DB value is `"Gemini 3"`, update it to `"Gemini 3.1 Pro"` and return the new value.
2. **Client-side:** In Settings `fetchData()`, map `selectedModel === "Gemini 3"` to `"Gemini 3.1 Pro"`, call `form.setValue()` with the mapped value, and optionally call `saveSelectedModel()` to persist.
### Fix Focus Areas
- components/settings/components/settings.tsx[84-99]
- lib/actions/users.ts[146-181]
- components/settings/components/model-selection-form.tsx[28-107]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@components/settings/components/model-selection-form.tsx`:
- Around line 46-58: Normalize any legacy saved model id "Gemini 3" to the new
id "Gemini 3.1 Pro" before comparing against SelectItem/RadioGroupItem options
in the ModelSelectionForm component; update the value used for rendering and
selection checks (the prop/state that feeds SelectItem/RadioGroupItem, e.g.,
selectedModel, value, or defaultValue) to map "Gemini 3" -> "Gemini 3.1 Pro" so
existing saved configs appear selected, and ensure the same normalization is
applied when initializing form state and when persisting changes.
In `@lib/utils/index.ts`:
- Around line 53-67: The console.error calls inside the Gemini branch currently
hard-code "Gemini 3.1 Pro"; update those error messages to use the actual
selected model label (the variable used in the switch, e.g., selectedModel) and
optionally include the resolved target ("gemini-3.1-pro") so telemetry reflects
whether "Gemini 3" or "Gemini 3.1 Pro" was chosen; modify the two console.error
invocations in the case handling that uses gemini3ProApiKey /
createGoogleGenerativeAI(...) to reference selectedModel (and the resolved
target string) instead of the fixed literal.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: da1f5c34-fdb7-41ba-9d28-2e0a5a6bae91
📒 Files selected for processing (4)
.env.local.exampleGEMINI_3.1_PRO_INTEGRATION.mdcomponents/settings/components/model-selection-form.tsxlib/utils/index.ts
📜 Review details
🔇 Additional comments (3)
.env.local.example (1)
20-21: Header update is consistent with runtime configuration.The rename to Gemini 3.1 Pro aligns with the integration, and keeping
GEMINI_3_PRO_API_KEYpreserves compatibility with current code paths.lib/utils/index.ts (1)
95-103: Gemini fallback now correctly targets 3.1 Pro.The default provider chain update to
gemini-3.1-pro-previewis consistent with the migration objective.GEMINI_3.1_PRO_INTEGRATION.md (1)
1-79: Documentation update is coherent with the code migration.The model name, provider priority, env var guidance, and model identifier are consistently updated to Gemini 3.1 Pro.
| id: "Gemini 3.1 Pro", | ||
| name: "Gemini 3.1 Pro", | ||
| description: "Google's latest reasoning model, excelling at multimodal understanding and complex agentic tasks.", | ||
| icon: Sparkles, | ||
| badge: "Multimodal", | ||
| badge: "Advanced", | ||
| badgeVariant: "outline" as const, | ||
| }, | ||
| { | ||
| id: "GPT-5.1", | ||
| name: "GPT-5.1", | ||
| description: "The cutting-edge of language models, offering unparalleled performance in creative and analytical tasks.", | ||
| icon: Zap, | ||
| badge: "Advanced", | ||
| badge: "Expert", |
There was a problem hiding this comment.
Normalize legacy "Gemini 3" form values before rendering options.
Line 46 removes the old option id, so existing saved values of "Gemini 3" won’t match any SelectItem/RadioGroupItem. Users can see an apparently unselected model despite having one configured.
Suggested patch
+const normalizeModelValue = (value?: string) =>
+ value === "Gemini 3" ? "Gemini 3.1 Pro" : value;
+
export function ModelSelectionForm({ form }: ModelSelectionFormProps) {
return (
@@
- <Select onValueChange={field.onChange} value={field.value}>
+ <Select onValueChange={field.onChange} value={normalizeModelValue(field.value)}>
@@
<RadioGroup
onValueChange={field.onChange}
- value={field.value}
+ value={normalizeModelValue(field.value)}
className="space-y-3"
>🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@components/settings/components/model-selection-form.tsx` around lines 46 -
58, Normalize any legacy saved model id "Gemini 3" to the new id "Gemini 3.1
Pro" before comparing against SelectItem/RadioGroupItem options in the
ModelSelectionForm component; update the value used for rendering and selection
checks (the prop/state that feeds SelectItem/RadioGroupItem, e.g.,
selectedModel, value, or defaultValue) to map "Gemini 3" -> "Gemini 3.1 Pro" so
existing saved configs appear selected, and ensure the same normalization is
applied when initializing form state and when persisting changes.
| case 'Gemini 3': | ||
| case 'Gemini 3.1 Pro': | ||
| if (gemini3ProApiKey) { | ||
| const google = createGoogleGenerativeAI({ | ||
| apiKey: gemini3ProApiKey, | ||
| }); | ||
| try { | ||
| return google('gemini-3-pro-preview'); | ||
| return google('gemini-3.1-pro-preview'); | ||
| } catch (error) { | ||
| console.error('Selected model "Gemini 3" is configured but failed to initialize.', error); | ||
| console.error('Selected model "Gemini 3.1 Pro" is configured but failed to initialize.', error); | ||
| throw new Error('Failed to initialize selected model.'); | ||
| } | ||
| } else { | ||
| console.error('User selected "Gemini 3" but GEMINI_3_PRO_API_KEY is not set.'); | ||
| console.error('User selected "Gemini 3.1 Pro" but GEMINI_3_PRO_API_KEY is not set.'); | ||
| throw new Error('Selected model is not configured.'); |
There was a problem hiding this comment.
Use the requested model label in Gemini error logs.
Line 62 and Line 66 always log "Gemini 3.1 Pro". If Line 53 ("Gemini 3") hits this branch, telemetry is misleading during migration/debugging. Log selectedModel (optionally with resolved target) instead.
Suggested patch
- console.error('Selected model "Gemini 3.1 Pro" is configured but failed to initialize.', error);
+ console.error(
+ `Selected model "${selectedModel}" (resolved to "Gemini 3.1 Pro") is configured but failed to initialize.`,
+ error
+ );
throw new Error('Failed to initialize selected model.');
}
} else {
- console.error('User selected "Gemini 3.1 Pro" but GEMINI_3_PRO_API_KEY is not set.');
+ console.error(
+ `User selected "${selectedModel}" (resolved to "Gemini 3.1 Pro") but GEMINI_3_PRO_API_KEY is not set.`
+ );
throw new Error('Selected model is not configured.');
}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@lib/utils/index.ts` around lines 53 - 67, The console.error calls inside the
Gemini branch currently hard-code "Gemini 3.1 Pro"; update those error messages
to use the actual selected model label (the variable used in the switch, e.g.,
selectedModel) and optionally include the resolved target ("gemini-3.1-pro") so
telemetry reflects whether "Gemini 3" or "Gemini 3.1 Pro" was chosen; modify the
two console.error invocations in the case handling that uses gemini3ProApiKey /
createGoogleGenerativeAI(...) to reference selectedModel (and the resolved
target string) instead of the fixed literal.
|
@coderabbitai Gemini 3.1 pro is not connected, grok is still inferencing. Debug the code for the right configuration. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chainLet me inspect the relevant code files to identify the root cause. 🏁 Script executed: Length of output: 26162
🔍 Debug FindingsRoot Cause 1 — Default Fallback Priority Prefers Grok (Most Likely)In If Fix: Either remove // Default behavior: Gemini -> Grok -> Bedrock -> OpenAI
+ if (gemini3ProApiKey) {
+ const google = createGoogleGenerativeAI({ apiKey: gemini3ProApiKey });
+ try {
+ return google('gemini-3.1-pro-preview');
+ } catch (error) {
+ console.warn('Gemini 3.1 Pro API unavailable, falling back:', error);
+ }
+ }
if (xaiApiKey) {
const xai = createXai({ apiKey: xaiApiKey, baseURL: 'https://api.x.ai/v1' });
try {
return xai('grok-4-fast-non-reasoning');
} catch (error) {
console.warn('xAI API unavailable, falling back:', error);
}
}
- if (gemini3ProApiKey) { ... }Root Cause 2 —
|
| Scenario | Cause |
|---|---|
| ① User not authenticated | getCurrentUserIdOnServer() returns null |
| ② DB column missing | selectedModel column doesn't exist — Drizzle migration not run → catch block returns null |
| ③ Preference not saved | Settings form doesn't call saveSelectedModel() on submit |
In all three cases, getSelectedModel() silently returns null, and Grok takes over.
✅ Fixes
Fix 1 — Reorder the Default Fallback (Critical)
In lib/utils/index.ts, swap Grok and Gemini in the fallback so Gemini 3.1 Pro is tried first:
- // Default behavior: Grok -> Gemini -> Bedrock -> OpenAI
+ // Default behavior: Gemini 3.1 Pro -> Grok -> Bedrock -> OpenAI
+ if (gemini3ProApiKey) {
+ const google = createGoogleGenerativeAI({ apiKey: gemini3ProApiKey });
+ try {
+ return google('gemini-3.1-pro-preview');
+ } catch (error) {
+ console.warn('Gemini 3.1 Pro API unavailable, falling back to next provider:', error);
+ }
+ }
if (xaiApiKey) {
const xai = createXai({ apiKey: xaiApiKey, baseURL: 'https://api.x.ai/v1' });
try {
return xai('grok-4-fast-non-reasoning');
} catch (error) {
console.warn('xAI API unavailable, falling back to next provider:');
}
}
- if (gemini3ProApiKey) {
- const google = createGoogleGenerativeAI({ apiKey: gemini3ProApiKey });
- try {
- return google('gemini-3.1-pro-preview');
- } catch (error) {
- console.warn('Gemini 3.1 Pro API unavailable, falling back to next provider:', error);
- }
- }Fix 2 — Check Your .env.local
Make sure this is present and set to a valid key:
GEMINI_3_PRO_API_KEY=your_actual_google_ai_api_key_hereWithout this, the Gemini branch is skipped entirely even after reordering.
Fix 3 — Verify the DB Migration Was Run
getSelectedModel() reads from users.selectedModel via Drizzle ORM. If the column doesn't exist in your database (migration not applied), the query throws and the catch block returns null silently. Check your schema and run migrations:
npx drizzle-kit push # or `migrate` depending on your setupThen verify the column exists:
SELECT column_name FROM information_schema.columns
WHERE table_name = 'users' AND column_name = 'selectedModel';Fix 4 — Verify the Settings Form Saves the Selection
Check that your settings page calls saveSelectedModel('Gemini 3.1 Pro') on form submission. You can add a quick log to confirm:
// In your settings form submit handler
const result = await saveSelectedModel(selectedModel);
console.log('[Settings] saveSelectedModel result:', result);Summary Checklist
- Set
GEMINI_3_PRO_API_KEYin.env.local - Reorder default fallback in
lib/utils/index.ts(Gemini first, Grok second) - Run Drizzle migration to ensure
selectedModelcolumn exists inuserstable - Confirm settings form calls
saveSelectedModel()successfully - Restart the dev server after
.env.localchanges (CTRL+Cthennpm run dev)
@ngoiyaeric Thank you for the feedback. I've addressed the issue by:
Gemini 3.1 Pro should now be correctly prioritized and connected. |
- Swap model priority to favor Gemini 3.1 Pro over Grok in `getModel` - Fix case-insensitive detection of Gemini models in `geospatial` tool - Update grounding model ID to `gemini-3.1-pro-preview` in `geospatial` tool - Set Gemini 3.1 Pro as the default selected model in settings - Update integration documentation to reflect the new priority order Co-authored-by: ngoiyaeric <115367894+ngoiyaeric@users.noreply.github.com>
2 participants
This PR updates the application to support Google's Gemini 3.1 Pro model.
Key changes:
gemini-3-pro-previewtogemini-3.1-pro-previewin thegetModelutility.switchcase to ensure users who already had "Gemini 3" selected are automatically upgraded to 3.1 Pro without any manual intervention.GEMINI_3_PRO_INTEGRATION.mdtoGEMINI_3.1_PRO_INTEGRATION.mdand updated its content..env.local.exampleto mention Gemini 3.1 Pro.Verified with unit tests for the
getModellogic.PR created automatically by Jules for task 8732759200226483373 started by @ngoiyaeric
Summary by CodeRabbit
New Features
Documentation