bytedance/deer-flow · warning · HTTPException

Input polishing is disabled

Error message

Input polishing is disabled

What it means

Raised by POST /input-polish with status 404 when config.input_polish.enabled is false. The endpoint exists but the feature is disabled in config.yaml, so it reports 404 (feature not available) rather than 403 — clients should treat this as 'no polishing capability' and simply skip polishing.

Source

Thrown at backend/app/gateway/routers/input_polish.py:73

    return f"Locale hint: {locale_hint}\n\nRewrite this draft while preserving its intent:\n<draft>\n{text}\n</draft>"


@router.post(
    "/input-polish",
    response_model=InputPolishResponse,
    summary="Polish Composer Input",
    description="Rewrite a draft message before it is sent. This does not create a thread run or persist any message.",
)
@require_permission("runs", "create")
async def polish_input(
    body: InputPolishRequest,
    request: Request,
    config: AppConfig = Depends(get_config),
) -> InputPolishResponse:
    del request  # Required by the auth decorator.

    if not config.input_polish.enabled:
        raise HTTPException(status_code=404, detail="Input polishing is disabled")

    # Validate the same normalized view of the input that we send to the model,
    # so the user-facing length boundary and the model input cannot disagree
    # (e.g. a padded draft passing the check but arriving with stray whitespace).
    text = body.text.strip()
    if not text:
        raise HTTPException(status_code=400, detail="Input text is required")

    max_chars = config.input_polish.max_chars
    if len(text) > max_chars:
        raise HTTPException(status_code=400, detail=f"Input text exceeds {max_chars} characters")

    model_name = config.input_polish.model_name
    try:
        raw = await run_oneshot_llm(
            system_instruction=_build_system_instruction(),
            user_content=_build_user_content(text, body.locale),
            run_name="input_polish",

View on GitHub (pinned to 1dd6ba1acb)

Solutions

  1. Enable the feature in config.yaml: set input_polish.enabled: true (then restart/reload the Gateway).
  2. Gate the UI polish affordance on the server-advertised feature state so users never reach the 404.
  3. If disabled intentionally, have the client catch 404 and send the draft unpolished.

Example fix

# before (config.yaml)
input_polish:
  enabled: false

# after
input_polish:
  enabled: true
  max_chars: 8000
  model_name: gpt-4o-mini
Defensive patterns

Strategy: type-guard

Validate before calling

// gate the UI affordance on server capability
const caps = await getServerCapabilities();
if (caps.input_polish?.enabled) showPolishButton();

Type guard

const inputPolishEnabled = (caps: Caps) => Boolean(caps?.input_polish?.enabled === true);

Try / catch

try { await polish({ text }); } catch (e) { if (e.status === 404) return text; /* feature off — skip */ throw e; }

Prevention

When it happens

Trigger: Calling the polish endpoint while config.yaml's input_polish section has enabled: false (or is defaulted off); a frontend build that always shows the polish button regardless of server feature flags; config hot-reload disabling the feature mid-session.

Common situations: Fresh deployments where input_polish is off by default to save LLM cost; disabling the feature in prod but the UI bundle still exposes the affordance; per-environment config divergence (enabled in dev, disabled in prod).

Related errors


AI-assisted analysis of bytedance/deer-flow@1dd6ba1acb (2026-08-14). Data as JSON: /api/errors/39a5ec840cf3871d. Report an issue: GitHub.