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
- Enable the feature in config.yaml: set input_polish.enabled: true (then restart/reload the Gateway).
- Gate the UI polish affordance on the server-advertised feature state so users never reach the 404.
- 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
- Check config.input_polish.enabled before exposing the polish action
- Treat 404 from polish as 'feature absent' and degrade silently
- Restart the Gateway after config changes
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
- Browser automation is not enabled
- Failed to load agents: ${res.statusText}
- Agent '${name}' not found
- Failed to update agent: ${res.statusText}
- Failed to delete agent: ${res.statusText}
AI-assisted analysis of bytedance/deer-flow@1dd6ba1acb (2026-08-14).
Data as JSON: /api/errors/39a5ec840cf3871d.
Report an issue: GitHub.