fix: prevent urlContext from being added to Vertex AI requests

[roomote]

Summary

This PR fixes issue #7968 where Google Gemini requests were incorrectly routed to Vertex AI after both providers were configured, causing the error: "urlContext parameter is not supported in Vertex AI".

Problem

When users configured both Google Vertex AI and Google Gemini providers, the application would incorrectly apply Gemini-specific parameters (like urlContext) to Vertex AI requests. This happened because both providers share the same GeminiHandler base class, and the urlContext tool was being added based solely on the enableUrlContext option without checking the provider type.

Solution

• Added an isVertex boolean property to GeminiHandler to track whether the instance is for Vertex AI or regular Gemini
• Modified the tool configuration logic to only add urlContext when:
  • enableUrlContext is true AND
  • The instance is NOT a Vertex provider (!this.isVertex)
• This ensures urlContext is only used with regular Gemini API, not Vertex AI

Changes

• src/api/providers/gemini.ts: Added isVertex property and conditional logic for urlContext
• src/api/providers/tests/vertex-gemini-urlcontext.spec.ts: Added comprehensive test suite with 7 test cases

Testing

✅ All new tests passing (7 tests)
✅ All existing Gemini tests passing (15 tests)
✅ All existing Vertex tests passing (5 tests)
✅ Linting and type checking passed

Test Coverage

The new test suite verifies:

• Gemini handler includes urlContext when enabled
• Gemini handler excludes urlContext when disabled
• Vertex handler never includes urlContext even when enabled
• Google Search grounding still works correctly for Vertex
• Provider switching behavior works as expected

Fixes #7968

---

Important

Fixes issue where urlContext was incorrectly applied to Vertex AI requests by adding a boolean to differentiate handlers and updating logic in GeminiHandler.

• Behavior:
  • Adds isVertex boolean to GeminiHandler to differentiate between Vertex AI and Gemini.
  • Modifies logic in GeminiHandler to apply urlContext only if enableUrlContext is true and isVertex is false.
• Testing:
  • Adds vertex-gemini-urlcontext.spec.ts with 7 test cases to verify correct handling of urlContext for both Gemini and Vertex AI.
  • Tests include scenarios for enabling/disabling urlContext and provider switching.
• Files:
  • Updates in gemini.ts to implement the new logic and property.

^{This description was created by for 7479672. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Reviewing my own code because apparently I trust no one, not even myself.

[roomote]

Consider adding a comment here explaining why this differentiation is necessary:

Suggested change

	private isVertex: boolean
	// Track whether this instance is for Vertex AI to prevent unsupported parameters like urlContext
	private isVertex: boolean

This would help future maintainers understand the purpose of this flag.

[roomote]

Is the nullish coalescing operator necessary here? Since TypeScript already has the optional parameter, you could make the default more explicit in the constructor signature:

Suggested change

	this.isVertex = isVertex ?? false
	constructor({ isVertex = false, ...options }: GeminiHandlerOptions) {

Then just use:

Suggested change

	this.isVertex = isVertex ?? false
	this.isVertex = isVertex

[roomote]

The test file comment could be more descriptive about what this test suite validates. Consider:

Suggested change

	// npx vitest run src/api/providers/__tests__/vertex-gemini-urlcontext.spec.ts
	// Tests for ensuring urlContext parameter is correctly handled between Gemini and Vertex AI providers
	// npx vitest run src/api/providers/__tests__/vertex-gemini-urlcontext.spec.ts

[roomote]

I notice we're accessing private properties using bracket notation here and throughout the tests. While this works, is this the best approach for test isolation? We might want to consider:

1. Using a proper mocking library that can handle private properties
2. Exposing a test-friendly method
3. Making the client property protected instead of private

What do you think would be the cleanest approach?

[daniel-lxs]

Closing as I'm not really sure what the issue is