bytedance/deer-flow · warning · HTTPException
Unsupported context_mode
Error message
Unsupported context_mode
What it means
Raised as HTTP 422 by POST /api/scheduled-tasks when body.context_mode is not one of the two supported values: 'fresh_thread_per_run' or 'reuse_thread'. It is a free-form string field validated in the handler, not by the Pydantic model, so bad values reach this check.
Source
Thrown at backend/app/gateway/routers/scheduled_tasks.py:78
async def list_scheduled_tasks(request: Request):
repo = get_scheduled_task_repo(request)
user = await get_optional_user_from_request(request)
if user is None:
return []
return await repo.list_by_user(str(user.id))
@router.post("/scheduled-tasks")
@require_permission("threads", "write")
async def create_scheduled_task(request: Request, body: ScheduledTaskCreateRequest):
config = get_config()
repo = get_scheduled_task_repo(request)
thread_store = get_thread_store(request)
user = await get_optional_user_from_request(request)
if user is None:
raise HTTPException(status_code=401, detail="Authentication required")
if body.context_mode not in {"fresh_thread_per_run", "reuse_thread"}:
raise HTTPException(status_code=422, detail="Unsupported context_mode")
if body.context_mode == "reuse_thread":
if not body.thread_id:
raise HTTPException(status_code=422, detail="reuse_thread requires thread_id")
if not await thread_store.check_access(body.thread_id, str(user.id), require_existing=True):
raise HTTPException(status_code=404, detail="Thread not found")
if body.schedule_type not in {"once", "cron"}:
raise HTTPException(status_code=422, detail="Unsupported schedule_type")
schedule_spec = dict(body.schedule_spec)
try:
validate_timezone(body.timezone)
if body.schedule_type == "cron":
raw_cron = schedule_spec.get("cron")
if not isinstance(raw_cron, str):
raise HTTPException(status_code=422, detail="cron schedule requires schedule_spec.cron")
schedule_spec["cron"] = normalize_cron_expression(raw_cron)
next_run_at = compute_next_run_at(
body.schedule_type,View on GitHub (pinned to 1dd6ba1acb)
Solutions
- Set context_mode to exactly 'fresh_thread_per_run' or 'reuse_thread'.
- If reusing a thread, also supply thread_id (see the separate 422).
- Pin the client against the backend's supported values — check the ScheduledTaskCreateRequest schema via /docs (OpenAPI).
Example fix
// before
{ "context_mode": "fresh-thread-per-run", ... }
// after
{ "context_mode": "fresh_thread_per_run", ... } Defensive patterns
Strategy: validation
Validate before calling
VALID_CONTEXT_MODES = {"fresh_thread_per_run", "reuse_thread"}
assert body["context_mode"] in VALID_CONTEXT_MODES, f"use one of {VALID_CONTEXT_MODES}" Type guard
type ContextMode = "fresh_thread_per_run" | "reuse_thread"; const isContextMode = (v: unknown): v is ContextMode => v === "fresh_thread_per_run" || v === "reuse_thread";
Prevention
- Define the two allowed values as a shared constant/enum in the client.
- Reject form submission client-side before hitting the API.
- Regenerate the client from the OpenAPI schema after backend upgrades.
When it happens
Trigger: Creating a task with context_mode omitted-but-overridden, misspelled ('fresh-thread-per-run'), or an unsupported value like 'shared'.
Common situations: Client written against older/newer API docs; hand-crafted JSON payloads; enum drift between frontend and backend versions.
Related errors
- reuse_thread requires thread_id
- Unsupported schedule_type
- cron schedule requires schedule_spec.cron
- {exc}
- once schedule must be in the future
AI-assisted analysis of bytedance/deer-flow@1dd6ba1acb (2026-08-14).
Data as JSON: /api/errors/ee9140025887bbe6.
Report an issue: GitHub.