cleveragents/cleveragents-core

Fork 3

UAT: `ProviderType.GEMINI` missing from `ProviderRegistry.FALLBACK_ORDER` — Gemini-only users never get auto-selected provider #4750

New issue

Open

opened 2026-04-08 18:52:42 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-08 18:52:42 +00:00

Owner

Summary

ProviderRegistry.FALLBACK_ORDER in src/cleveragents/providers/registry.py does not include ProviderType.GEMINI. Since GEMINI and GOOGLE use different API keys (GEMINI_API_KEY vs GOOGLE_API_KEY) and are registered as separate entries in PROVIDER_KEY_ATTRS, a user who sets only GEMINI_API_KEY (without GOOGLE_API_KEY) will never have Gemini selected as the default provider via the fallback chain.

Expected Behavior

When GEMINI_API_KEY is set and no CLEVERAGENTS_DEFAULT_PROVIDER is configured, ProviderRegistry.get_default_provider_type() should return ProviderType.GEMINI via the fallback order.

Actual Behavior

# src/cleveragents/providers/registry.py

FALLBACK_ORDER: ClassVar[list[ProviderType]] = [
    ProviderType.OPENAI,
    ProviderType.ANTHROPIC,
    ProviderType.GOOGLE,      # ← uses GOOGLE_API_KEY
    ProviderType.AZURE,
    ProviderType.OPENROUTER,
    ProviderType.GROQ,
    ProviderType.TOGETHER,
    ProviderType.COHERE,
    # ProviderType.GEMINI is MISSING ← bug
]

get_default_provider_type() iterates over FALLBACK_ORDER and calls is_provider_configured() for each. Since GEMINI is not in the list, it is never checked. A user with only GEMINI_API_KEY set will get:

registry = ProviderRegistry()
registry.get_default_provider_type()  # Returns None — should return ProviderType.GEMINI

This causes create_ai_provider() and create_llm() to raise ValueError: No AI provider configured even though Gemini is fully configured.

Impact

Users who configure only GEMINI_API_KEY (not GOOGLE_API_KEY) cannot use the auto-discovery feature
get_default_provider_type() returns None even when Gemini is configured
create_ai_provider() raises ValueError: No AI provider configured for Gemini-only setups
The GEMINI provider type is effectively unreachable via auto-discovery

Code Location

src/cleveragents/providers/registry.py — FALLBACK_ORDER class variable (lines ~200–210)

Fix Direction

Add ProviderType.GEMINI to FALLBACK_ORDER, positioned after ProviderType.GOOGLE (since they share the same underlying model family):

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

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

## Summary `ProviderRegistry.FALLBACK_ORDER` in `src/cleveragents/providers/registry.py` does not include `ProviderType.GEMINI`. Since `GEMINI` and `GOOGLE` use **different** API keys (`GEMINI_API_KEY` vs `GOOGLE_API_KEY`) and are registered as separate entries in `PROVIDER_KEY_ATTRS`, a user who sets only `GEMINI_API_KEY` (without `GOOGLE_API_KEY`) will never have Gemini selected as the default provider via the fallback chain. ## Expected Behavior When `GEMINI_API_KEY` is set and no `CLEVERAGENTS_DEFAULT_PROVIDER` is configured, `ProviderRegistry.get_default_provider_type()` should return `ProviderType.GEMINI` via the fallback order. ## Actual Behavior ```python # src/cleveragents/providers/registry.py FALLBACK_ORDER: ClassVar[list[ProviderType]] = [ ProviderType.OPENAI, ProviderType.ANTHROPIC, ProviderType.GOOGLE, # ← uses GOOGLE_API_KEY ProviderType.AZURE, ProviderType.OPENROUTER, ProviderType.GROQ, ProviderType.TOGETHER, ProviderType.COHERE, # ProviderType.GEMINI is MISSING ← bug ] ``` `get_default_provider_type()` iterates over `FALLBACK_ORDER` and calls `is_provider_configured()` for each. Since `GEMINI` is not in the list, it is never checked. A user with only `GEMINI_API_KEY` set will get: ```python registry = ProviderRegistry() registry.get_default_provider_type() # Returns None — should return ProviderType.GEMINI ``` This causes `create_ai_provider()` and `create_llm()` to raise `ValueError: No AI provider configured` even though Gemini is fully configured. ## Impact - Users who configure only `GEMINI_API_KEY` (not `GOOGLE_API_KEY`) cannot use the auto-discovery feature - `get_default_provider_type()` returns `None` even when Gemini is configured - `create_ai_provider()` raises `ValueError: No AI provider configured` for Gemini-only setups - The `GEMINI` provider type is effectively unreachable via auto-discovery ## Code Location - `src/cleveragents/providers/registry.py` — `FALLBACK_ORDER` class variable (lines ~200–210) ## Fix Direction Add `ProviderType.GEMINI` to `FALLBACK_ORDER`, positioned after `ProviderType.GOOGLE` (since they share the same underlying model family): ```python FALLBACK_ORDER: ClassVar[list[ProviderType]] = [ ProviderType.OPENAI, ProviderType.ANTHROPIC, ProviderType.GOOGLE, ProviderType.GEMINI, # ← add here ProviderType.AZURE, ProviderType.OPENROUTER, ProviderType.GROQ, ProviderType.TOGETHER, ProviderType.COHERE, ] ``` --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 referenced this issue

2026-04-08 18:55:48 +00:00

[Automated] CleverAgents Build Session - 2026-04-08 #4743

HAL9000 added the

labels

2026-04-08 23:00:41 +00:00

HAL9000 commented

2026-04-09 03:05:00 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: Medium — spec compliance bug identified by UAT testing
Story Points: 3 (M) — targeted fix to align implementation with spec
MoSCoW: Must Have — spec compliance is required for correct system behavior

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Verified - **Priority**: Medium — spec compliance bug identified by UAT testing - **Story Points**: 3 (M) — targeted fix to align implementation with spec - **MoSCoW**: Must Have — spec compliance is required for correct system behavior --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 added

and removed

labels

2026-04-09 03:05:12 +00:00

HAL9000 added this to the v3.5.0 milestone

2026-04-09 03:05:12 +00:00

HAL9000 referenced this issue

2026-04-28 08:37:38 +00:00

TDD: ProviderType.GEMINI missing from ProviderRegistry.FALLBACK_ORDER — Gemini-only users never get auto-selected provider (#4750) #10896

HAL9000 referenced this issue

2026-04-28 09:24:03 +00:00

test(providers): add TDD failing test for GEMINI missing from FALLBACK_ORDER #10902

HAL9000 referenced this issue from a commit

2026-04-28 09:38:10 +00:00

fix(providers): add ProviderType.GEMINI to ProviderRegistry.FALLBACK_ORDER

HAL9000 referenced this issue from a pull request that will close it,

2026-04-28 10:07:38 +00:00

fix(providers): add ProviderType.GEMINI to ProviderRegistry.FALLBACK_ORDER #10906

HAL9000 referenced this issue from a commit

2026-04-28 10:51:49 +00:00

fix(providers): add ProviderType.GEMINI to ProviderRegistry.FALLBACK_ORDER

HAL9000 commented

2026-04-28 10:55:44 +00:00

Author

Owner

Implementation Attempt — Tier 3: sonnet — Success

Summary

Implemented the fix for ProviderType.GEMINI missing from ProviderRegistry.FALLBACK_ORDER following the mandatory TDD bug fix workflow.

What Was Done

Step 1: Created TDD Issue

Created TDD issue #10896: "TDD: ProviderType.GEMINI missing from ProviderRegistry.FALLBACK_ORDER"

Step 2: Wrote Failing TDD Test

Created features/tdd_gemini_fallback_order_4750.feature with @tdd_issue @tdd_issue_4750 @tdd_expected_fail tags
Created features/steps/tdd_gemini_fallback_order_4750_steps.py with step definitions
Test fails via AssertionError (GEMINI not in FALLBACK_ORDER → returns None)
@tdd_expected_fail inverts result so CI passes while bug exists

Step 3: Merged TDD PR

TDD PR #10902 merged to master (all CI checks passing)
TDD issue #10896 closed

Step 4: Implemented the Fix

Added ProviderType.GEMINI to FALLBACK_ORDER after ProviderType.GOOGLE in src/cleveragents/providers/registry.py
Removed @tdd_expected_fail tag from TDD test (fix applied)
Added new BDD scenarios to features/provider_registry_coverage.feature verifying GEMINI is in FALLBACK_ORDER
Added new step definitions for GEMINI fallback order verification

Step 5: Created Bugfix PR

Bugfix PR #10906 created on branch bugfix/m6-gemini-fallback-order
PR closes #4750

Quality Gates

lint ✓
typecheck ✓
CI running on bugfix PR

Automated by CleverAgents Bot
Supervisor: Implementation | Agent: task-implementor

**Implementation Attempt** — Tier 3: sonnet — Success ## Summary Implemented the fix for `ProviderType.GEMINI` missing from `ProviderRegistry.FALLBACK_ORDER` following the mandatory TDD bug fix workflow. ## What Was Done ### Step 1: Created TDD Issue - Created TDD issue #10896: "TDD: ProviderType.GEMINI missing from ProviderRegistry.FALLBACK_ORDER" ### Step 2: Wrote Failing TDD Test - Created `features/tdd_gemini_fallback_order_4750.feature` with `@tdd_issue @tdd_issue_4750 @tdd_expected_fail` tags - Created `features/steps/tdd_gemini_fallback_order_4750_steps.py` with step definitions - Test fails via `AssertionError` (GEMINI not in FALLBACK_ORDER → returns None) - `@tdd_expected_fail` inverts result so CI passes while bug exists ### Step 3: Merged TDD PR - TDD PR #10902 merged to master (all CI checks passing) - TDD issue #10896 closed ### Step 4: Implemented the Fix - Added `ProviderType.GEMINI` to `FALLBACK_ORDER` after `ProviderType.GOOGLE` in `src/cleveragents/providers/registry.py` - Removed `@tdd_expected_fail` tag from TDD test (fix applied) - Added new BDD scenarios to `features/provider_registry_coverage.feature` verifying GEMINI is in FALLBACK_ORDER - Added new step definitions for GEMINI fallback order verification ### Step 5: Created Bugfix PR - Bugfix PR #10906 created on branch `bugfix/m6-gemini-fallback-order` - PR closes #4750 ## Quality Gates - lint ✓ - typecheck ✓ - CI running on bugfix PR --- Automated by CleverAgents Bot Supervisor: Implementation | Agent: task-implementor