GoodJob
A Rails ActiveJob backend with a dashboard and concurrency extensions.
View pinned source / version 1d73ef089e8b · Feature claims below describe this pinned source snapshot; the version constant is not evidence that all changes at HEAD shipped in that release.
What this system is built around
A Postgres-backed ActiveJob backend for Rails with threads, scheduling, an integrated dashboard and concurrency extensions. Default job claims use advisory locks; current main also documents an experimental SKIP LOCKED mode.
Useful to evaluate when a Rails application wants an ActiveJob-native queue with operational UI and recurring jobs. Compare its default advisory mode separately from the newer experimental SKIP LOCKED mode when planning connection pooling or upgrades.
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
DocumentedDefault claims use session-level advisory locks. Current main documents :skiplocked, which writes lock state to the jobs table, and :hybrid for mixed rolling deployments. This snapshot evidence does not establish that those main changes are in the latest release.
Transactional enqueue
QualifiedEnqueue persists a GoodJob::Job via ActiveRecord save!. The adapter’s enqueue_after_transaction_commit setting defaults false. Sharing the application’s database connection and keeping enqueue inside its transaction can make the insert atomic; using a separate connection/database or deferred enqueue changes that boundary. This is a source-derived conditional claim.
Crash recovery & retries
DocumentedDocs say interrupted jobs are automatically retried, including SIGKILL/power failure. Ordinary exceptions instead rely on ActiveJob retry_on by default. GoodJob.retry_on_unhandled_error=true enables immediate infinite retries and docs warn of high load.
Delayed & recurring work
DocumentedActiveJob delayed jobs and built-in cron are documented. Cron is opt-in (enable_cron); unique indexes suppress duplicate enqueue of a given fire interval, requiring preserved cron job records.
Uniqueness / deduplication
QualifiedGoodJob extensions offer enqueue/perform/total limits and throttles scoped by labels, plus cron-fire uniqueness. Docs warn about some state/race nuances and describe optimistic retry for perform limits. Do not equate those controls with exactly-once external effects.
Postgres extension required
Not requiredREADME explicitly says the advisory-lock key derivation does not require PostgreSQL extensions. Compatibility section lists Postgres10+, Rails6.1+ and Ruby3.0+ for this snapshot.
Operator interface
DocumentedCore README includes a mounted dashboard with job browsing, retries, cron and related operational views.
Tradeoffs to carry into a test
Unhandled task errors are not retried by default; configure ActiveJob retry_on or explicitly choose GoodJob’s unhandled-error behavior. Interrupted processes are handled separately.
Recovery and retries Recovery and retriesDefault advisory locks and LISTEN need persistent connections. Experimental skiplocked mode has additional required settings for transaction pooling.
Claims and concurrencyConcurrency limits and cron deduplication have different semantics from an external-provider idempotency key.
Uniqueness scope Scheduling Recovery and retriesFeatures are sourced from pinned main after the v4.22.1 release; do not assume every main change shipped in 4.22.1.
Snapshot commit and date Published v4.22.1 release