Solid Queue
Rails job infrastructure with SQL dispatch and explicit failure records.
View pinned source / version 73602fe39b95 · 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 database-backed Rails ActiveJob backend supporting PostgreSQL, MySQL and SQLite. It combines short SKIP LOCKED polling with separate ready/scheduled/failed execution records and process supervision.
Useful to evaluate for Rails applications seeking a framework-integrated database queue, especially when portability beyond Postgres matters. Its separate queue-database default and explicit failed-job handling need to fit the application’s transaction and recovery expectations.
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
DocumentedPostgreSQL9.5+ supports the SKIP LOCKED path used to avoid waiting behind other workers. Workers, dispatchers and scheduler have different roles; process heartbeats, not handler deadlines, track liveness.
Transactional enqueue
QualifiedDocs describe transactional enqueue when jobs share the application database/connection and transaction, but default configuration uses a different database. Rails enqueue_after_transaction_commit defers enqueue after commit and does not provide the same atomic handoff.
Crash recovery & retries
QualifiedExpired process heartbeats and abnormal process exits mark claimed jobs failed with ProcessPrunedError/ProcessExitError. Docs explicitly say these are not automatically retried; ActiveJob retry_on cannot catch errors recorded after the process has died. FailedExecution#retry or external automation can re-enqueue them.
Delayed & recurring work
DocumentedDelayed work is dispatched when due; recurring tasks use a scheduler and recurring.yml, with Fugit schedule parsing.
Uniqueness / deduplication
Qualifiedlimits_concurrency uses key/group semaphores. Default conflicts block; on_conflict:discard can suppress conflicting enqueues. Duration is a release failsafe and does not establish strict execution order or universal exactly-once effects.
Postgres extension required
No extra documentedThe documented Postgres path uses regular tables and SKIP LOCKED, with no additional Postgres extension specified. Rails/ActiveJob dependencies and schema migration remain required.
Operator interface
QualifiedREADME points to Mission Control—Jobs as a dashboard rather than describing a bundled Solid Queue UI. Its installation/version was not separately audited here.
Tradeoffs to carry into a test
By default the queue uses a separate database, so application-write/queue-insert atomicity must not be assumed.
Transaction integrationAbrupt worker death marks in-flight work failed; automatic recovery retry is deliberately not provided. ActiveJob retry_on does not catch process-prune errors recorded by a surviving process.
Recovery and retries Recovery and retries Recovery and retriesConcurrency controls are time-bounded semaphores; expiry is not a hard guarantee that an old process stopped.
Uniqueness scopeFeatures describe pinned main after release1.7.0; no assumption every current-main change shipped in1.7.0.
Snapshot commit and date Published v1.7.0 release