Skip to content

Schedule generation failure handling: one retry, preserved task buffer #6

Description

@cristoforows

Parent

#2 (PRD: /timebox — LLM-assisted next-day timeboxing)

What to build

Make /timebox schedule generation resilient to LLM flakiness. Builds directly on the scheduler module from #5.

Behavior:

  1. When the structured-output call fails (API error, timeout, or output that fails Pydantic validation), automatically retry once. The retry may re-send the request as-is or include a corrective instruction — implementer's choice, but keep it to exactly one automatic retry.
  2. If the retry also fails: send the user a clear error message stating that scheduling failed and that they can send /done again to retry. The collected task buffer MUST remain intact and the conversation MUST remain in a state where /done re-triggers generation with the same tasks — the user never re-types their list.
  3. /cancel still aborts and clears the buffer from this state; the 30-minute inactivity timeout still applies.
  4. A subsequent successful /done clears the buffer and ends the session normally.

Extend the existing pytest suite (introduced in #5) with fake-LLM tests: first call fails → retry succeeds → valid schedule returned; both calls fail → error surfaced and caller can re-invoke with the same task list successfully. Test external behavior only.

Manual verification: point TIMEBOX_LLM_MODEL at a nonexistent model, run /timebox → tasks → /done, confirm the error message, then restore the model and confirm /done succeeds without re-entering tasks.

Acceptance criteria

  • A single transient LLM failure is invisible to the user (retry succeeds, schedule delivered)
  • Two consecutive failures produce a user-facing error that explicitly says /done can be retried
  • After a failed generation, /done re-runs with the identical task list — no re-typing
  • /cancel and the 30-minute timeout still work from the failed state
  • pytest covers retry-success and double-failure paths with a fake LLM, offline

Blocked by

Metadata

Metadata

Assignees

No one assigned

    Labels

    ready-for-agentTriage: ready for an AFK agent to pick up

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions