fix(web): archive tasks from the board and release provably dead runs - #105
Conversation
Two ways a work item became permanently stuck.
There was no delete or archive path at all — not in the UI, not in the
API. 'archivedAt' existed and every list already filtered on it, but
nothing could set it, so the only way to clear a task was a manual
database update.
- PATCH /api/v1/tasks/[id] accepts { archived }, audited as
task.archived / task.restored.
- Soft delete, never a row delete, so audit events that reference the
task keep their target.
- Archiving is refused while a run is queued or running: hiding a task
whose agent is still burning budget and may still write evidence is
worse than leaving it visible. Cancel first.
Cancel itself could wedge. It called the gateway and threw on any
failure, so a run the gateway had lost — dead worker, expired lease —
could never be released, leaving the task undeletable and
undispatchable at once.
Cancel now force-releases a run only when it provably cannot still be
executing: both the lease and the deadline have passed, or the run row
is gone. Anything else still refuses with 502 rather than reporting a
run cancelled while the gateway may still be running it. A forced
release records that the gateway did not confirm, and why.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 14 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Two separate ways a work item became permanently stuck. Reported as "stuck jobs queued in the task board that I can't delete" — that's actually both problems at once.
There was no delete or archive path anywhere
Not in the UI, not in the API.
archivedAtexisted on the table and every list already filtered on it, but nothing could set it — the only way to clear a task was a manual database update. (That's what I had to do earlier to clean up my own verification tasks, which should have tipped me off then.)PATCH /api/v1/tasks/[id]now accepts{ archived }, audited astask.archived/task.restored.Cancel could wedge, which is what made them unrecoverable
POST /api/v1/tasks/[id]/cancelcalled the gateway and threw on any failure. So a run the gateway had lost — dead worker, expired lease, orphaned record — could never be released. That left the task simultaneously undeletable (no archive path) and undispatchable (A run is already in flight). Permanently stuck, by construction.Cancel now force-releases a run only when it provably cannot still be executing: both the lease and the deadline have passed, or the run row is gone entirely.
Anything else still refuses, with a
502and an explicit message, because the alternative is worse than a stuck task: Muster reporting a run cancelled while the gateway is still executing it, and an operator dispatching a second one on top. A forced release records that the gateway did not confirm and why, both incancellationReasonand the response.Note
I could not reproduce a genuinely wedged run on the homelab — the one queued task settled to
completedwhile I was inspecting it, which is the#100settle fix working. So this is a fix for the class of failure, verified by reading the paths rather than by reproducing one. The force-release rule is deliberately conservative for that reason.🤖 Generated with Claude Code