cleveragents/cleveragents-core

Fork 3

UAT: `create_ai_provider(provider_type="gemini")` falls through to generic `LangChainChatProvider` without API key injection — Gemini API key silently ignored #4754

New issue

Open

opened 2026-04-08 18:53:28 +00:00 by HAL9000 · 1 comment

HAL9000 commented

2026-04-08 18:53:28 +00:00

Owner

Summary

ProviderRegistry.create_ai_provider() in src/cleveragents/providers/registry.py has no dedicated branch for ProviderType.GEMINI. While ProviderType.GOOGLE has a branch that creates a GoogleChatProvider with the API key explicitly injected, ProviderType.GEMINI falls through to the generic LangChainChatProvider path. This path creates an llm_factory closure that calls _create_provider_llm(), which does handle GEMINI — but it does not pass the API key to ChatGoogleGenerativeAI. The API key is silently ignored, and the LLM relies on the GOOGLE_API_KEY or GEMINI_API_KEY environment variable being set at the OS level.

Expected Behavior

create_ai_provider(provider_type="gemini") should return a GoogleChatProvider (or equivalent) with the GEMINI_API_KEY explicitly injected, consistent with how GOOGLE, OPENAI, ANTHROPIC, and OPENROUTER are handled.

Actual Behavior

# src/cleveragents/providers/registry.py — create_ai_provider()

if provider_type == ProviderType.OPENAI:
    # ✓ Explicit API key injection via OpenAIChatProvider
    ...

if provider_type == ProviderType.ANTHROPIC:
    # ✓ Explicit API key injection via AnthropicChatProvider
    ...

if provider_type == ProviderType.GOOGLE:
    # ✓ Explicit API key injection via GoogleChatProvider
    ...

# ProviderType.GEMINI — NO BRANCH ← bug
# Falls through to generic LangChainChatProvider path:

def llm_factory(mid: str) -> BaseLanguageModel:
    return self._create_provider_llm(
        resolved_provider_type,  # = ProviderType.GEMINI
        mid,
        max_retries=max_retries,
        # ← No api_key kwarg passed!
    )

Inside _create_provider_llm():

if provider_type in (ProviderType.GOOGLE, ProviderType.GEMINI):
    from langchain_google_genai import ChatGoogleGenerativeAI
    return ChatGoogleGenerativeAI(
        model=model_id or "gemini-2.0-flash",
        **kwargs,
        # ← api_key NOT in kwargs — relies on env var
    )

The result is that ChatGoogleGenerativeAI is created without an explicit api_key, so it falls back to reading GOOGLE_API_KEY or GEMINI_API_KEY from the environment. This bypasses the Settings-managed key and means the registry's own key validation is ineffective for Gemini.

Impact

create_ai_provider("gemini") does not inject the API key from Settings.gemini_api_key
If GEMINI_API_KEY is set in Settings but not in the OS environment, the LLM will fail to authenticate
Inconsistent behavior: GOOGLE gets explicit key injection, GEMINI does not
The is_configured check in ProviderInfo becomes misleading — the registry says Gemini is configured but the LLM won't use the configured key

Code Location

src/cleveragents/providers/registry.py — create_ai_provider() method (lines ~600–700), missing ProviderType.GEMINI branch

Fix Direction

Add a dedicated ProviderType.GEMINI branch in create_ai_provider() that mirrors the GOOGLE branch:

if provider_type in (ProviderType.GOOGLE, ProviderType.GEMINI):
    from cleveragents.providers.llm.google_provider import GoogleChatProvider

    key_attr = self.PROVIDER_KEY_ATTRS.get(provider_type)
    api_key = getattr(self._settings, key_attr, None) if key_attr else None
    if not api_key:
        missing_env = (
            key_attr.upper() if key_attr else provider_type.value.upper()
        )
        raise ValueError(
            f"Provider {provider_type.value} is not configured. "
            f"Please set the {missing_env} environment variable."
        )

    return GoogleChatProvider(
        api_key=api_key,
        model=model_id or self.DEFAULT_MODELS.get(provider_type, "gemini-2.0-flash"),
        max_retries=max_retries,
    )

Similarly, _create_provider_llm() should accept and pass through an api_key kwarg for the Google/Gemini branch.

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

## Summary `ProviderRegistry.create_ai_provider()` in `src/cleveragents/providers/registry.py` has no dedicated branch for `ProviderType.GEMINI`. While `ProviderType.GOOGLE` has a branch that creates a `GoogleChatProvider` with the API key explicitly injected, `ProviderType.GEMINI` falls through to the generic `LangChainChatProvider` path. This path creates an `llm_factory` closure that calls `_create_provider_llm()`, which does handle `GEMINI` — but it does **not** pass the API key to `ChatGoogleGenerativeAI`. The API key is silently ignored, and the LLM relies on the `GOOGLE_API_KEY` or `GEMINI_API_KEY` environment variable being set at the OS level. ## Expected Behavior `create_ai_provider(provider_type="gemini")` should return a `GoogleChatProvider` (or equivalent) with the `GEMINI_API_KEY` explicitly injected, consistent with how `GOOGLE`, `OPENAI`, `ANTHROPIC`, and `OPENROUTER` are handled. ## Actual Behavior ```python # src/cleveragents/providers/registry.py — create_ai_provider() if provider_type == ProviderType.OPENAI: # ✓ Explicit API key injection via OpenAIChatProvider ... if provider_type == ProviderType.ANTHROPIC: # ✓ Explicit API key injection via AnthropicChatProvider ... if provider_type == ProviderType.GOOGLE: # ✓ Explicit API key injection via GoogleChatProvider ... # ProviderType.GEMINI — NO BRANCH ← bug # Falls through to generic LangChainChatProvider path: def llm_factory(mid: str) -> BaseLanguageModel: return self._create_provider_llm( resolved_provider_type, # = ProviderType.GEMINI mid, max_retries=max_retries, # ← No api_key kwarg passed! ) ``` Inside `_create_provider_llm()`: ```python if provider_type in (ProviderType.GOOGLE, ProviderType.GEMINI): from langchain_google_genai import ChatGoogleGenerativeAI return ChatGoogleGenerativeAI( model=model_id or "gemini-2.0-flash", **kwargs, # ← api_key NOT in kwargs — relies on env var ) ``` The result is that `ChatGoogleGenerativeAI` is created without an explicit `api_key`, so it falls back to reading `GOOGLE_API_KEY` or `GEMINI_API_KEY` from the environment. This bypasses the `Settings`-managed key and means the registry's own key validation is ineffective for Gemini. ## Impact - `create_ai_provider("gemini")` does not inject the API key from `Settings.gemini_api_key` - If `GEMINI_API_KEY` is set in `Settings` but not in the OS environment, the LLM will fail to authenticate - Inconsistent behavior: `GOOGLE` gets explicit key injection, `GEMINI` does not - The `is_configured` check in `ProviderInfo` becomes misleading — the registry says Gemini is configured but the LLM won't use the configured key ## Code Location - `src/cleveragents/providers/registry.py` — `create_ai_provider()` method (lines ~600–700), missing `ProviderType.GEMINI` branch ## Fix Direction Add a dedicated `ProviderType.GEMINI` branch in `create_ai_provider()` that mirrors the `GOOGLE` branch: ```python if provider_type in (ProviderType.GOOGLE, ProviderType.GEMINI): from cleveragents.providers.llm.google_provider import GoogleChatProvider key_attr = self.PROVIDER_KEY_ATTRS.get(provider_type) api_key = getattr(self._settings, key_attr, None) if key_attr else None if not api_key: missing_env = ( key_attr.upper() if key_attr else provider_type.value.upper() ) raise ValueError( f"Provider {provider_type.value} is not configured. " f"Please set the {missing_env} environment variable." ) return GoogleChatProvider( api_key=api_key, model=model_id or self.DEFAULT_MODELS.get(provider_type, "gemini-2.0-flash"), max_retries=max_retries, ) ``` Similarly, `_create_provider_llm()` should accept and pass through an `api_key` kwarg for the Google/Gemini branch. --- **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:40 +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:10 +00:00

HAL9000 added this to the v3.5.0 milestone