Job States

Documentation Index

Fetch the complete documentation index at: https://docs.sluice.sh/llms.txt

Use this file to discover all available pages before exploring further.

Sluice uses a normalized state model with eight states. This abstraction exists because the architecture supports multiple job queue frameworks — Celery today, BullMQ and Sidekiq in the future — each with different native state machines.

​

Unified states

​

The PENDING problem

Celery’s PENDING state is uniquely confusing. The Celery documentation itself notes it would be “better named ‘unknown’” because it’s the default state for any task ID — including ones that don’t exist. If you query Celery for the state of task abc123 and get PENDING, that could mean:

• The task was dispatched and is waiting in the queue
• The task ID is a typo and no such task was ever created
• The task completed hours ago and the result backend has already expired the record

Sluice addresses this by tracking the task-sent event (enabled by task_send_sent_event=True). When Sluice sees a task-sent event, it creates the job record with state queued. A task that Sluice has never seen remains unknown — and the dashboard makes the distinction clear.

​

State transitions

Jobs move through states in a predictable flow: Every transition is recorded in the job’s state history, which you can view in the Job Detail page or retrieve via the API.

​

Management actions by state

Not every state allows every action. The available management actions depend on the job’s current state: Attempting an action on a job in a disallowed state returns a 400 error with a descriptive message.