hzhang 3baa990604 fix(tasks): tolerate out-of-enum task_type/status on read (stop list 500) ...

TaskResponse inherited task_type: TaskTypeEnum (TaskBase) and declared
status: TaskStatusEnum. The tasks table column is a free-form String(32), so
a single row whose task_type/status falls outside the strict enum (e.g.
seeded rows with task_type='setup' or 'recruit') made pydantic raise a
ValidationError while serializing the list — taking down `GET /tasks` /
`hf task list` entirely with HTTP 500 (no --status filter, --status open, and
--project all 500'd; only filters that happened to exclude the bad rows
worked).

Override task_type and status as plain str on TaskResponse so reads surface
legacy/unknown values verbatim instead of crashing the whole list. Writes stay
strict: TaskCreate/TaskBase still use the enums and create is gated by
_validate_task_type_subtype (ALLOWED_TASK_TYPES); TaskUpdate still uses the
enums.

Verified on sim: `hf task list` (and --status open / --project) now return all
rows including task_type='setup'/'recruit' instead of 500.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-10 21:24:14 +01:00

12 KiB

Raw Blame History

View Raw