Durabull Documentation

Queue Operations

Perform queue-level control actions including pause, resume, status-based purge, clean, delete, and obliterate.

Route Scope

Queue detail route:

  • /$orgSlug/c/$connectionId/queues/$queueName

This page combines queue summary, jobs table, and scheduled-job tab.

Available Queue Controls

Pause/Resume Queue

  • POST /api/c/:connectionId/queues/:queueName/pause
  • POST /api/c/:connectionId/queues/:queueName/resume

Pause prevents workers from picking up new jobs; jobs already active continue processing. Use it during downstream outages or maintenance, and resume after the underlying issue is resolved.

Clean Queue by Status

  • POST /api/c/:connectionId/queues/:queueName/clean
  • Requires status; optional gracePeriod in milliseconds (default 0) and limit (default 1000).

Supported clean statuses are completed, failed, delayed, paused, waiting, active, and prioritized (mapped internally to BullMQ equivalents).

Purge Queue Jobs (Guarded + Multi-Status)

  • POST /api/c/:connectionId/queues/:queueName/purge
  • Requires:
    • confirmName (must exactly match queue name)
    • statuses (one or more specific statuses, or ["all"])

Purge removes jobs in the selected states. It excludes waiting-children and does not remove schedulers.

Operational behavior:

  • users can select any status combination (waiting, active, delayed, completed, failed, paused, prioritized)
  • users can choose all supported statuses via statuses: ["all"]
  • confirmation input only authorizes purge when exact queue name is entered

Response includes:

  • statusesPurged
  • totalRemoved
  • removedByStatus
  • removedJobIdsSample (sample only)

Optional keepMostRecent preserves the newest N jobs across the selected statuses (default 0, maximum 1000000). Locked jobs may remain or cause a conflict, depending on the removal path. A purge is not atomic: a 409 can occur after some jobs have already been removed.

Purge Flow in the UI

  1. Open queue detail settings menu.
  2. Choose Purge Jobs.
  3. Select one or more statuses, or All jobs.
  4. Type exact queue name to enable the destructive action.
  5. Submit purge and verify updated queue counts.

Obliterate Queue

  • POST /api/c/:connectionId/queues/:queueName/obliterate

Forcefully removes queue data and its discovery index entry. Unlike the guarded delete endpoint, this endpoint does not require confirmName or check job counts. Stop producers and workers before using it; a running application can recreate the queue.

Delete Queue (Guarded)

  • DELETE /api/c/:connectionId/queues/:queueName
  • Requires confirmName that must match queue name
  • Refuses deletion while waiting, active, delayed, failed, paused, or prioritized jobs remain.
  • Completed jobs do not block deletion; deletion removes their data too.
  • The pre-flight check does not count waiting-children; inspect dependent jobs separately.

Use pre-flight check route:

  • GET /api/c/:connectionId/queues/:queueName/can-delete

Safe Deletion Procedure

  1. Stop producers, remove schedulers that would create new jobs, and stop workers after active jobs finish.
  2. Purge or clean the supported states, then inspect and handle waiting-children separately.
  3. Confirm queue is deletable via can-delete.
  4. Delete with exact queue name confirmation.