RQ

Requires RQ 1.10+ and <3, Python 3.10+. See the compatibility matrix for the full pin string.

Install

pip install z4j-rq

What it captures

RQ doesn’t expose signals in the Celery sense - z4j hooks Queue.enqueue_call and patches Worker.work to emit lifecycle events.

Hook	z4j event
`Queue.enqueue_call`	`task_sent`
`Worker.perform_job` (start)	`task_started`
job success	`task_succeeded`
job failure	`task_failed`
job requeue	`task_retry`

Actions

Verb	How
`retry`	`Queue.enqueue` with original function + args, mark old as `retried_as`
`cancel`	`send_stop_job_command(connection, job_id)` if running; `job.cancel()` if queued
`purge_queue`	`queue.empty()`
`bulk_retry`	loop, capped at 10k

Multiple queues

RQ uses many queues per app. The agent discovers all queues on first connection via Queue.all(connection). Each queue appears separately in the dashboard with its own counts.

RQ-worker-pool

rq-worker-pool works fine - each worker in the pool registers as its own agent. Use agent_name with $PID to distinguish.

Caveats

Failed queue - RQ moves failures to a special failed registry. z4j reads this on first connect and emits synthetic task_failed events for visibility.
Scheduler read-only - schedule CRUD for rq-scheduler is not currently shipped; the dashboard displays existing schedules but creating or editing them via z4j is disabled for this adapter.
Dependencies - job.depends_on chains show in the dashboard as “waiting on”.

Config

No explicit config; reads Redis connection from RQ itself.

Multiple Redis targets:

Z4J = {
    ...,
    "rq": {"connection": "myapp.redis.rq_conn"},
}

See scheduler: rq-scheduler.