bytedance/deer-flow · warning · HTTPException
Unsupported schedule_type
Error message
Unsupported schedule_type
What it means
Raised as HTTP 422 by POST /api/scheduled-tasks when schedule_type is not 'once' or 'cron'. Like context_mode, it is a string validated in-handler rather than a Pydantic enum, so arbitrary strings reach this branch.
Source
Thrown at backend/app/gateway/routers/scheduled_tasks.py:85
@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,
schedule_spec,
body.timezone,
now=datetime.now(UTC),
)
except ValueError as exc:
raise HTTPException(status_code=422, detail=str(exc)) from exc
View on GitHub (pinned to 1dd6ba1acb)
Solutions
- Use exactly 'once' (single future run) or 'cron' (recurring).
- For recurring schedules, express the pattern as a cron expression in schedule_spec.cron.
- Check the OpenAPI schema at /docs for the accepted request shape.
Example fix
// before
{ "schedule_type": "interval", "schedule_spec": { "every_minutes": 5 } }
// after
{ "schedule_type": "cron", "schedule_spec": { "cron": "*/5 * * * *" } } Defensive patterns
Strategy: validation
Validate before calling
VALID_SCHEDULE_TYPES = {"once", "cron"}
assert body["schedule_type"] in VALID_SCHEDULE_TYPES, f"use one of {VALID_SCHEDULE_TYPES}" Type guard
type ScheduleType = "once" | "cron"; const isScheduleType = (v: unknown): v is ScheduleType => v === "once" || v === "cron";
Prevention
- Constrain the schedule-type control to a two-option enum in the UI.
- Express recurring schedules as cron strings, not custom interval objects.
When it happens
Trigger: Creating a task with schedule_type such as 'interval', 'recurring', or a typo like 'Once'.
Common situations: Clients expecting interval schedules the backend does not support; case mismatches; payload schema drift.
Related errors
- cron schedule requires schedule_spec.cron
- {exc}
- Unsupported context_mode
- reuse_thread requires thread_id
- once schedule must be in the future
AI-assisted analysis of bytedance/deer-flow@1dd6ba1acb (2026-08-14).
Data as JSON: /api/errors/49a817714fb9402d.
Report an issue: GitHub.