srbhr/Resume-Matcher · warning · HTTPException

Unsupported content language: {request.content_language}. Su

Error message

Unsupported content language: {request.content_language}. Supported: {SUPPORTED_LANGUAGES}

What it means

A 400 HTTPException raised by update_language_config when request.content_language is provided but not in SUPPORTED_LANGUAGES. Same whitelist mechanism as the ui_language check, applied to the content language that governs generated cover letters/outreach content.

Source

Thrown at apps/backend/app/routers/config.py:330

async def update_language_config(
    request: LanguageConfigRequest,
) -> LanguageConfigResponse:
    """Update language configuration."""
    stored = _load_config()

    # Validate and update UI language
    if request.ui_language is not None:
        if request.ui_language not in SUPPORTED_LANGUAGES:
            raise HTTPException(
                status_code=400,
                detail=f"Unsupported UI language: {request.ui_language}. Supported: {SUPPORTED_LANGUAGES}",
            )
        stored["ui_language"] = request.ui_language

    # Validate and update content language
    if request.content_language is not None:
        if request.content_language not in SUPPORTED_LANGUAGES:
            raise HTTPException(
                status_code=400,
                detail=f"Unsupported content language: {request.content_language}. Supported: {SUPPORTED_LANGUAGES}",
            )
        stored["content_language"] = request.content_language

    # Save config
    _save_config(stored)

    # Support legacy single 'language' field migration
    legacy_language = stored.get("language", "en")

    return LanguageConfigResponse(
        ui_language=stored.get("ui_language", legacy_language),
        content_language=stored.get("content_language", legacy_language),
        supported_languages=SUPPORTED_LANGUAGES,
    )

View on GitHub (pinned to 116f9cc3b0)

Solutions

Send a content_language exactly matching a value in SUPPORTED_LANGUAGES
Fetch the supported list from the backend options endpoint and restrict the UI picker to it
Omit content_language from the request to leave it unchanged

Example fix

// before
await api.updateLanguageConfig({ content_language: 'de-DE' })
// after
await api.updateLanguageConfig({ content_language: 'de' })

Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED = await api.getSupportedLanguages()
if (contentLang && !SUPPORTED.includes(contentLang)) {
  throw new Error(`content_language ${contentLang} not in ${SUPPORTED}`)
}

Try / catch

try {
  await api.updateLanguageConfig({ content_language: lang })
} catch (e) {
  if (e.response?.status === 400 && String(e.response.data.detail).startsWith('Unsupported content language')) {
    showToast(`Content language ${lang} is not supported`)
  } else throw e
}

Prevention

Restrict the content-language UI to values returned by the backend options endpoint
Map unsupported locales to nearest supported language
Omit content_language when unchanged
Keep frontend and backend language lists in sync via a shared source

When it happens

Trigger: PUT/POST language config with content_language not in SUPPORTED_LANGUAGES, e.g. 'de-DE' when only 'de' is supported, or a language the backend cannot generate content in.

Common situations: Client offers more language options than the backend supports; user selects a language from an OS locale that isn't whitelisted; config synced from another deployment with a different SUPPORTED_LANGUAGES set.

Related errors

AI-assisted analysis of srbhr/Resume-Matcher@116f9cc3b0 (2026-08-28). Data as JSON: /api/errors/4aaf59d0cc4282db. Report an issue: GitHub.