Que
A focused Ruby queue built around advisory locks and transaction control.
View pinned source / version 57cfa4a4d4ad · Pinned master source reports version 2.4.1. GitHub’s latest non-prerelease release endpoint reported v2.4.0 (2024-08-20), so its date is not presented as the release date of this 2.4.1 source snapshot.
What this system is built around
A Ruby/Postgres job queue built around session advisory locks, multithreaded workers and database transactions. Native Que jobs can put application writes and job destruction inside the same transaction.
A focused choice to evaluate for Ruby applications using ActiveRecord or Sequel that want transaction control without a separate broker. Native Que jobs expose stronger database integration than the generic ActiveJob adapter.
Editorial fit, based on the cited design. Verify against your workload.Semantics & operating model
Concise claims with their scope intact. “Not verified” means this review did not establish the answer.
Claiming & concurrency
DocumentedWorkers coordinate with PostgreSQL advisory locks; the worker process is multithreaded. Locking does not itself require updating the job row.
Transactional enqueue
QualifiedEnqueue can piggyback on ActiveRecord/Sequel connections and commit or roll back with application data. Native Que jobs may destroy/finish themselves in the same application transaction. Docs warn the ActiveJob adapter loses the ability to finish a job inside the same transaction as other operations.
Crash recovery & retries
DocumentedAdvisory locks disappear when a worker’s connection dies, making unfinished jobs available. Error retries use an increasing interval and maximum_retry_count; docs describe a default15 retries. Crash recovery can repeat a partially completed handler.
Delayed & recurring work
QualifiedNative jobs support future run_at and priority. The README lists que-scheduler as a separate cron-style project, under related projects described as tested for Que1.x; current2.x compatibility is unverified.
Uniqueness / deduplication
Not verifiedNo general native uniqueness feature was verified. README links que-unique and que-locks as companion projects tested with Que1.x; this is not evidence of bundled2.x deduplication.
Postgres extension required
No extra documentedThe documented setup migrates Que’s schema in PostgreSQL; no separate Postgres extension is specified. README’s server minimum is PostgreSQL9.5+.
Operator interface
Not verifiedREADME lists que-web and que-view, not a bundled UI, and labels those related projects as Que1.x-compatible. Compatibility with this2.x snapshot was not checked.
Tradeoffs to carry into a test
The core docs explicitly allow repeated execution after a crash; external side effects still require duplicate-safe design.
Transaction integrationSession advisory locking needs a direct/session connection; a separate connection-url can bypass transaction-pooled app connections.
Separate direct locking connectionLong transactions can prevent vacuum cleanup and degrade the high-churn job table.
High-churn table vacuum requirements Installation and prerequisitesThe related scheduler/UI/uniqueness projects are listed as Que 1.x-compatible; compatibility with this2.x snapshot was not verified.
Scheduling