Skip to content

feat: Refactor Gemini and Vertex handlers to be fully independent #4374

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
3 tasks done
kiwina opened this issue Jun 5, 2025 · 1 comment · May be fixed by #4375
Open
3 tasks done

feat: Refactor Gemini and Vertex handlers to be fully independent #4374

kiwina opened this issue Jun 5, 2025 · 1 comment · May be fixed by #4375
Labels
enhancement New feature or request Issue - In Progress Someone is actively working on this. Should link to a PR soon.

Comments

@kiwina
Copy link

kiwina commented Jun 5, 2025

Summary

Refactor the Gemini and Vertex model provider handlers to be fully independent, eliminating shared logic and inheritance. This improves code maintainability, reduces coupling, and ensures each handler operates with provider-specific logic.

Problem

Currently, the VertexHandler inherits from GeminiHandler, which creates several issues:

  • Mixed vertex and gemini logic in both handlers
  • Vertex-specific parameters polluting the Gemini constructor
  • Shared inheritance making debugging and maintenance difficult
  • Model selection confusion between providers

Solution

  1. Complete Independence: Make VertexHandler a standalone class that doesn't inherit from GeminiHandler
  2. Clean Separation: Remove all vertex-related logic from GeminiHandler
  3. Provider-Specific Models: Ensure each handler uses only its own model set and defaults
  4. Enhanced Debugging: Add comprehensive debug output to trace model selection

Changes Made

GeminiHandler (src/api/providers/gemini.ts)

  • Removed all vertex-related constructor parameters (isVertex, vertex credentials)
  • Removed vertex-specific logic and model handling
  • Now uses only geminiApiKey and geminiModels
  • Clean, gemini-only implementation

VertexHandler (src/api/providers/vertex.ts)

  • Complete standalone implementation (no inheritance)
  • Uses only vertex-specific credentials and configuration
  • Implements all required methods independently
  • Enhanced debug output in getModel() method for troubleshooting
  • Uses vertexModels and vertexDefaultModelId exclusively

Tests Updated

  • Updated vertex test expectations to use correct default model (claude-sonnet-4@20250514)
  • Fixed error message expectations after refactoring
  • All tests passing (11 vertex tests, 15 gemini tests)

Benefits

  • Cleaner Architecture: Each handler is responsible only for its provider
  • Easier Debugging: Clear separation makes issues easier to trace
  • Better Maintainability: Changes to one provider don't affect the other
  • Reduced Coupling: No shared state or inheritance dependencies
  • Provider-Specific Optimization: Each handler can be optimized for its specific use case

Testing

  • ✅ All existing gemini tests pass (15/15)
  • ✅ All vertex tests updated and passing (11/11)
  • ✅ No breaking changes to public API
  • ✅ Model selection and fallback logic verified
  • ✅ Debug output added for troubleshooting apiModelId flow

Files Changed

  • src/api/providers/gemini.ts - Refactored to pure Gemini implementation
  • src/api/providers/vertex.ts - Standalone Vertex implementation with enhanced debugging
  • src/api/providers/__tests__/vertex.test.ts - Updated test expectations

Type of Change

  • Refactor (code change that improves structure without changing functionality)
  • Enhancement (improvement to existing feature)
  • Test updates (updating existing tests)

This refactoring improves code quality while maintaining full backward compatibility and makes future maintenance much easier.

@kiwina
Copy link
Author

kiwina commented Jun 5, 2025

PS: adds API key And Global to Vertex

@hannesrudolph hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Jun 5, 2025
@daniel-lxs daniel-lxs moved this from Triage to Issue [In Progress] in Roo Code Roadmap Jun 5, 2025
@daniel-lxs daniel-lxs added Issue - In Progress Someone is actively working on this. Should link to a PR soon. and removed Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. labels Jun 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Issue - In Progress Someone is actively working on this. Should link to a PR soon.
Projects
Status: Issue [In Progress]
Development

Successfully merging a pull request may close this issue.

3 participants