Skip to main content
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.