UAT: GEMINI provider type missing from ProviderRegistry.FALLBACK_ORDER despite being a supported provider #6053

New issue

Open

opened 2026-04-09 14:11:08 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-09 14:11:08 +00:00

Owner

Bug Report

Summary

ProviderType.GEMINI is a registered provider type with full capability metadata, a default model, and API key configuration (gemini_api_key), but it is absent from ProviderRegistry.FALLBACK_ORDER. This means users who configure only a GEMINI_API_KEY will never have Gemini selected as the default provider via the fallback mechanism.

What Was Tested

Inspected src/cleveragents/providers/registry.py — FALLBACK_ORDER class variable
Cross-referenced with ProviderType enum, DEFAULT_CAPABILITIES, DEFAULT_MODELS, and PROVIDER_KEY_ATTRS

Expected Behavior

All configured providers should be reachable via the fallback selection mechanism. If a user sets only GEMINI_API_KEY, the system should select Gemini as the default provider.

Actual Behavior

ProviderRegistry.FALLBACK_ORDER (lines ~200–210 in registry.py):

FALLBACK_ORDER: ClassVar[list[ProviderType]] = [
    ProviderType.OPENAI,
    ProviderType.ANTHROPIC,
    ProviderType.GOOGLE,
    ProviderType.AZURE,
    ProviderType.OPENROUTER,
    ProviderType.GROQ,
    ProviderType.TOGETHER,
    ProviderType.COHERE,
    # ProviderType.GEMINI — MISSING
]

ProviderType.GEMINI is fully configured:

DEFAULT_CAPABILITIES[ProviderType.GEMINI] — defined (streaming, tool calls, vision, 1M context, JSON mode)
DEFAULT_MODELS[ProviderType.GEMINI] = "gemini-2.0-flash"
PROVIDER_KEY_ATTRS[ProviderType.GEMINI] = "gemini_api_key"

But it is NOT in FALLBACK_ORDER.

Impact

When a user sets GEMINI_API_KEY (without GOOGLE_API_KEY):

ProviderRegistry.get_default_provider_type() iterates through FALLBACK_ORDER
ProviderType.GEMINI is never checked
Returns None — "no provider configured"
System raises ValueError: No AI provider configured

This is a regression risk: users who specifically use the Gemini API key (separate from Google AI Studio key) cannot use the system without also setting GOOGLE_API_KEY.

Note: GOOGLE and GEMINI are treated as separate providers in the registry — GOOGLE uses google_api_key (Google AI Studio), while GEMINI uses gemini_api_key (Gemini API). Both map to ChatGoogleGenerativeAI but with different API keys.

Code Location

src/cleveragents/providers/registry.py — FALLBACK_ORDER class variable (~line 200)

Fix

Add ProviderType.GEMINI to FALLBACK_ORDER, positioned after ProviderType.GOOGLE:

FALLBACK_ORDER: ClassVar[list[ProviderType]] = [
    ProviderType.OPENAI,
    ProviderType.ANTHROPIC,
    ProviderType.GOOGLE,
    ProviderType.GEMINI,  # ADD THIS
    ProviderType.AZURE,
    ProviderType.OPENROUTER,
    ProviderType.GROQ,
    ProviderType.TOGETHER,
    ProviderType.COHERE,
]

Also note: Settings._PROVIDER_FALLBACK_ORDER (in settings.py) includes "gemini" in its fallback order, but ProviderRegistry.FALLBACK_ORDER does not — these two fallback lists are inconsistent and should be reconciled.

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Bug Report ### Summary `ProviderType.GEMINI` is a registered provider type with full capability metadata, a default model, and API key configuration (`gemini_api_key`), but it is **absent from `ProviderRegistry.FALLBACK_ORDER`**. This means users who configure only a `GEMINI_API_KEY` will never have Gemini selected as the default provider via the fallback mechanism. ### What Was Tested - Inspected `src/cleveragents/providers/registry.py` — `FALLBACK_ORDER` class variable - Cross-referenced with `ProviderType` enum, `DEFAULT_CAPABILITIES`, `DEFAULT_MODELS`, and `PROVIDER_KEY_ATTRS` ### Expected Behavior All configured providers should be reachable via the fallback selection mechanism. If a user sets only `GEMINI_API_KEY`, the system should select Gemini as the default provider. ### Actual Behavior `ProviderRegistry.FALLBACK_ORDER` (lines ~200–210 in `registry.py`): ```python FALLBACK_ORDER: ClassVar[list[ProviderType]] = [ ProviderType.OPENAI, ProviderType.ANTHROPIC, ProviderType.GOOGLE, ProviderType.AZURE, ProviderType.OPENROUTER, ProviderType.GROQ, ProviderType.TOGETHER, ProviderType.COHERE, # ProviderType.GEMINI — MISSING ] ``` `ProviderType.GEMINI` is fully configured: - `DEFAULT_CAPABILITIES[ProviderType.GEMINI]` — defined (streaming, tool calls, vision, 1M context, JSON mode) - `DEFAULT_MODELS[ProviderType.GEMINI]` = `"gemini-2.0-flash"` - `PROVIDER_KEY_ATTRS[ProviderType.GEMINI]` = `"gemini_api_key"` But it is NOT in `FALLBACK_ORDER`. ### Impact When a user sets `GEMINI_API_KEY` (without `GOOGLE_API_KEY`): 1. `ProviderRegistry.get_default_provider_type()` iterates through `FALLBACK_ORDER` 2. `ProviderType.GEMINI` is never checked 3. Returns `None` — "no provider configured" 4. System raises `ValueError: No AI provider configured` This is a regression risk: users who specifically use the Gemini API key (separate from Google AI Studio key) cannot use the system without also setting `GOOGLE_API_KEY`. Note: `GOOGLE` and `GEMINI` are treated as separate providers in the registry — `GOOGLE` uses `google_api_key` (Google AI Studio), while `GEMINI` uses `gemini_api_key` (Gemini API). Both map to `ChatGoogleGenerativeAI` but with different API keys. ### Code Location `src/cleveragents/providers/registry.py` — `FALLBACK_ORDER` class variable (~line 200) ### Fix Add `ProviderType.GEMINI` to `FALLBACK_ORDER`, positioned after `ProviderType.GOOGLE`: ```python FALLBACK_ORDER: ClassVar[list[ProviderType]] = [ ProviderType.OPENAI, ProviderType.ANTHROPIC, ProviderType.GOOGLE, ProviderType.GEMINI, # ADD THIS ProviderType.AZURE, ProviderType.OPENROUTER, ProviderType.GROQ, ProviderType.TOGETHER, ProviderType.COHERE, ] ``` Also note: `Settings._PROVIDER_FALLBACK_ORDER` (in `settings.py`) includes `"gemini"` in its fallback order, but `ProviderRegistry.FALLBACK_ORDER` does not — these two fallback lists are inconsistent and should be reconciled. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 14:15:59 +00:00

HAL9000 added a new dependency

2026-04-09 14:28:33 +00:00

#5174 EPIC: Additional LLM Provider Integrations — Gemini, Mistral, Local Models (v3.6.0)

HAL9000 added the

MoSCoW