Is your feature request related to a problem? Please describe.

Queues are automatically created when tasks are deployed, but there is no way to delete or archive them when they are no longer needed. When a task is removed from code and redeployed, its queue persists in the database and on the dashboard forever. The same happens when queues are renamed — the old queue remains with no way to remove it.

We at getclera.com run 100+ queues and have been iterating on our task architecture - renaming queues, removing tasks, restructuring workflows. This has left us with many stale, orphaned queues cluttering the Queues dashboard. There is no delete button, no archive option, no API endpoint, and no automatic cleanup on redeploy. The only option to "disable" a queue is pausing it, but paused queues still show up in the list.

Describe the solution you'd like to see

At minimum, allow users to hide or soft-delete queues from the dashboard:

1. Soft-delete / archive: Add a deletedAt (or archivedAt) timestamp column to the TaskQueue model. Archived queues are filtered out of the dashboard and API list responses by default. An optional filter could show archived queues if needed.
2. UI action: Add a "Delete" or "Archive" option to the existing queue menu (next to Pause/Resume and Override concurrency).
3. API endpoint: Add DELETE /api/v1/queues/:queueId (or POST /api/v1/queues/:queueId/archive) so this can be automated.
4. Auto-cleanup on deploy (nice to have): When a new worker version is deployed, detect queues that are no longer referenced by any active task and automatically archive them — similar to how declarative schedules are already cleaned up in createBackgroundWorker.server.ts.

Describe alternate solutions

Alternates, none of them sound reasonable/ technical sound:

Hard delete: Actually remove the TaskQueue row from the database. This is problematic because TaskRunAttempt has a cascading foreign key to TaskQueue — deleting a queue would delete all its execution history. Not recommended without first migrating the FK to SET NULL.

• Filter by activity: Instead of deletion, add a dashboard filter to hide queues with 0 queued and 0 running. This partially addresses the clutter but doesn't help with renamed/orphaned queues that may briefly get new runs routed to them.
• Bulk cleanup API: A one-time script endpoint to delete all queues not associated with the current active worker version (not a fan)

Additional information

Codebase findings that support this request:

• No delete mechanism exists: There is no delete API route, no soft-delete field (deletedAt, archived, status) on the TaskQueue model, and no cleanup code anywhere in the codebase.
• Queues are created automatically in apps/webapp/app/v3/services/createBackgroundWorker.server.ts (line ~441) via prisma.taskQueue.create() during deployment, but are never removed when tasks are deleted from code.
• Schedules ARE cleaned up on redeploy (same file, lines ~501-659) — orphaned declarative schedules are detected and deleted. This pattern could be extended to queues.
• Cascade delete risk: TaskRunAttempt has onDelete: Cascade to TaskQueue in the Prisma schema — hard-deleting a queue would destroy run attempt history. A soft-delete approach avoids this entirely.
• The paused field (Boolean) is the only existing queue state control, added in migration 20250318090847_pause_queues_and_environments. It does not hide queues from the list.
• All query code (QueueListPresenter.server.ts, resource routes, API routes) would need to filter out soft-deleted queues — currently they filter only by version: "V2" and optional name/type filters.