unslothai/unsloth · error · HTTPException

Unknown provider type: {payload.provider_type}

Error message

Unknown provider type: {payload.provider_type}

What it means

A 400 from the connectivity-test endpoint: after _bind_saved_provider_target resolved the payload, get_provider_info(payload.provider_type) returned None. The provider_type string (possibly inherited from a saved provider row or sent directly) is not in the provider registry, so no probe can be constructed. Note this message variant does not include the registry hint — compare with the create-endpoint variant which does.

Source

Thrown at studio/backend/routes/providers.py:481

@router.post("/test", response_model = ProviderTestResult)
async def test_provider(
    payload: ProviderTestRequest,
    _current_subject: str = Depends(get_current_subject),
    via_api_key: bool = Depends(authenticated_via_api_key),
):
    """
    Test connectivity to an external provider.

    Makes a lightweight GET /models call to verify the API key works. Generic
    custom endpoints use a chat-completions probe because /models is optional.
    An explicit encrypted key takes precedence over the saved provider key.
    """

    payload = _bind_saved_provider_target(payload)
    info = get_provider_info(payload.provider_type)
    if info is None:
        raise HTTPException(
            status_code = 400,
            detail = f"Unknown provider type: {payload.provider_type}",
        )

    api_key = resolve_provider_api_key_or_400(
        payload.provider_id,
        payload.encrypted_api_key,
        allow_saved_key = not via_api_key,
    )

    base_url = payload.base_url or info["base_url"]
    if payload.provider_type == "custom":
        if not base_url:
            return ProviderTestResult(
                success = False,
                message = "Connection failed: Base URL is required for custom providers.",
                models_count = None,
            )

View on GitHub (pinned to 203007d190)

Solutions

1. GET /api/providers/registry and use an exact, current provider_type id.
2. If a saved provider row has an obsolete type, recreate the provider with a current type (POST) and delete the stale row.
3. Send the payload with an explicit provider_type and encrypted_api_key to bypass stale saved config.

const registry = await fetch("/api/providers/registry").then(r => r.json());
const valid = new Set(registry.types.map(t => t.id));
const effectiveType = payload.encrypted_api_key ? payload.provider_type : savedProvider?.provider_type;
if (!valid.has(effectiveType)) throw new Error(`Unknown provider type: ${effectiveType}`);

try { await testConnectivity(payload); } catch (e) { if (e.status === 400 && /Unknown provider type/i.test(e.detail)) { await refreshRegistryAndProviders(); return; } throw e; }

When it happens

Trigger: POST test-connectivity with a typo'd or removed provider_type; a saved provider row whose stored provider_type no longer exists in this backend version; sending provider_id of a legacy row without an explicit key so the stale stored type is used.

Common situations: Backend upgrades that renamed provider types while old rows persist; clients hardcoding type ids; hand-crafted test payloads.

Related errors

• model load did not reach ready
• unknown family '{name}'
• Refused notebook fetch from {host!r}: not in allowlist {sort
• Cell uses shell metacharacters / interpolation but --no-allo
• load error: {backend.load_progress()}

AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15). Data as JSON: /api/errors/20d8e52dc97c728e. Report an issue: GitHub.