rails/solid_queue

Solid Queue is a standalone Active Job adapter for Rails that manages background job processing through a robust, multi-process architecture. It provides advanced features such as job batching with lifecycle callbacks, concurrency control via semaphores, and support for both static and dynamic recurring tasks. The system includes a supervisor to orchestrate workers, dispatchers, and schedulers, with integration support for Puma and flexible execution modes including forked processes and fiber-based async workers.

26 changes.

This period marks the extraction of the database-backed job queue into the standalone Solid Queue gem, replacing the previous active\_job-database\_queue integration. The work introduced a robust, multi-process architecture with supervisor-managed workers, supporting both forked and fiber-based execution modes. Key features added include batch processing, concurrency controls, queue pausing, and comprehensive integration with Puma and Rails.

10 changes.

This period focused on introducing job batching capabilities, including lifecycle tracking, callbacks, and migration generators, alongside dynamic recurring task scheduling and command-based job definitions. The supervisor was refactored for better maintainability, and PostgreSQL query performance was optimized using recursive CTEs. Comprehensive integration tests and updated Rails compatibility matrices were also added to support these new features.

Introduces a new Puma plugin (\lib/puma/plugin/solid\_queue.rb\) that allows Solid Queue to run either as a forked child process or in async mode within the Puma server. The plugin supports both Puma 6 and Puma 7 hook names, handles process monitoring to stop Solid Queue on Puma restart or stop, and includes safeguards against deadlocks during shutdown by skipping Ruby's at-exit cleanup in forked processes.

lib/puma · high confidence

An update generator has been added to copy new migration templates for batch support, including the creation of the solid\_queue\_batches and solid\_queue\_batch\_executions tables and the addition of batch\_id to solid\_queue\_jobs, allowing users to upgrade their existing Solid Queue setup to support job batching.

_lib/generators/solid\queue/update · high confidence

This change introduces SolidQueue as a new, standalone gem for job processing, replacing the previous \active\_job-database\_queue\ integration. The library provides a complete process-based architecture featuring a Supervisor, Dispatcher, Scheduler, and Worker, all managed via a Zeitwerk autoloader. It exposes a public API for configuring process lifecycles (start, stop, exit hooks), managing recurring tasks, and tuning operational parameters such as heartbeat intervals, shutdown timeouts, and concurrency control. The adapter defaults to preserving finished jobs and uses SKIP LOCKED for database locking, offering a robust, multi-process foundation for Active Job.

lib · high confidence

Adds the SolidQueue adapter, allowing users to configure Active Job to use SolidQueue as the backend by setting \queue\_adapter\ to \:solid\_queue\. This adapter implements standard enqueueing methods (\enqueue\, \enqueue\_at\, \enqueue\_all\) that delegate to \SolidQueue::Job\, and enforces \enqueue\_after\_transaction\_commit\ as a permanent \true\ setting. It also provides a \stopping?\ method that checks a global worker shutdown flag, accepting an optional job argument for compatibility with newer Rails versions.

_lib/active\_job/queue\adapters · high confidence

Active Job now supports job batching and concurrency limiting. A new \BatchId\ module allows jobs to track their membership in a batch, enabling batch-level callbacks and status tracking. Additionally, a \ConcurrencyControls\ module introduces the \limits\_concurrency\ DSL, allowing developers to define concurrency keys, limits, groups, and conflict behaviors (block or discard) to manage how jobs execute concurrently. The previous \database\_queue\ engine structure has been removed as part of this refactoring.

_lib/active\job · high confidence

The Solid Queue gem now provides an \install\ generator (\bin/rails generate solid\_queue:install\) that automates the initial configuration. Running this command copies over default configuration files (\config/queue.yml\, \config/recurring.yml\), installs a database schema (\db/queue\_schema.rb\), and adds a \bin/jobs\ binstub to start the supervisor. It also automatically configures the application to use Solid Queue as the Active Job adapter in the production environment and sets up the necessary database connection settings.

_lib/generators/solid\queue/install · high confidence

Solid Queue now supports running workers and dispatchers in the same process as the supervisor via a new 'async' mode, in addition to the existing 'fork' mode. This is enabled by the new AsyncSupervisor class, which manages supervised processes as threads rather than child processes, and the FiberPool, which allows workers to execute jobs using Ruby fibers (requiring the 'async' gem and fiber-scoped isolation). The update also introduces lifecycle hooks (start, stop, exit) for processes, a new AppExecutor to wrap code in Rails' application executor, and a CLI check command to validate configuration before starting.

_lib/solid\queue · high confidence

Solid Queue now supports job batching, allowing users to group jobs and track their collective progress, status (pending, enqueued, completed, failed), and completion percentages. The system includes automatic cleanup of finished batches, handling of stalled or crashed batches via a sweep mechanism, and the ability to define callbacks that trigger specific jobs upon batch success, failure, or completion.

_app/models/solid\_queue/batch, app/models/solid\_queue/failed\execution · high confidence

Solid Queue now supports grouping jobs into batches via the new \Batch\ and \BatchExecution\ models, allowing users to track completion and failure counts for groups of jobs. It adds concurrency control using \Semaphore\ and \BlockedExecution\ models to limit parallel job execution based on keys and durations. Additionally, users can pause and resume individual queues using the \Pause\ model and \Queue\ wrapper, and the system now tracks process lifecycles with heartbeats via the \Process\ model.

_app/models/solid\queue · high confidence

The SolidQueue job model has been refactored to support advanced queueing features. Jobs can now be grouped into batches for coordinated execution and progress tracking via the new Batchable concern. Concurrency limits are enforced using semaphores, allowing jobs to be blocked or discarded based on class-level configuration. The model also introduces explicit states for scheduled, ready, claimed, and failed executions, enabling better handling of retries, discards, and recurring tasks. Additionally, finished jobs can be automatically cleared after a configurable time period.

_app/models/solid\queue/job · high confidence

The scheduler now supports dynamically scheduled recurring tasks, allowing jobs to be added or removed at runtime rather than only via static configuration. This capability is opt-in and controlled by the \dynamic\_tasks\_enabled\ option; when enabled, the scheduler loads dynamic tasks from the database, schedules new ones, and unschedules removed ones during each cycle. The implementation ensures thread safety and prevents stale state by wrapping database reads and task scheduling in an app executor and clearing changes appropriately within the scheduler loop.

_lib/solid\queue/scheduler · high confidence

The SolidQueue \DistinctValues\ module now uses a recursive Common Table Expression (CTE) to emulate a loose index scan on PostgreSQL, replacing the standard \DISTINCT\ query for large tables. This change improves performance by avoiding full index scans when retrieving distinct values for a leading index column, while still respecting current scopes and bind parameters.

_app/models/solid\queue/record · high confidence

The Solid Queue process management logic has been restructured by extracting pruning and execution handling into dedicated concerns (Prunable and Executor). This change ensures that when a process is pruned due to inactivity, any jobs it has claimed but not yet completed are explicitly failed with a ProcessPrunedError, rather than being left in a limbo state. Additionally, the Executor concern ensures that claimed executions are released when a process is destroyed, improving cleanup reliability for workers and supervisors.

_app/models/solid\queue/process · high confidence

The Solid Queue execution model now explicitly manages how it inherits attributes from its associated job, allowing configurable attribute assumption (such as queue name and priority) via a new \JobAttributes\ concern. Additionally, a new \Dispatching\ concern was introduced to handle the lifecycle of scheduled jobs, specifically providing a \dispatch\_jobs\ method that dispatches a batch of jobs and subsequently deletes their corresponding execution records.

_app/models/solid\queue/execution · high confidence

The internal process architecture has been restructured to support a unified base class and distinct execution modes (inline, async, and fork). This change introduces a new \Processes::Base\ class and modular concerns like \Runnable\ and \Supervised\, enabling processes to run in separate threads or OS forks with proper boot guards and signal handling. Users benefit from more robust process management, including better handling of graceful shutdowns, automatic replacement of failed forked workers, and clearer instrumentation of process lifecycle events.

_lib/solid\queue/processes · high confidence

The Solid Queue supervisor's internal structure has been reorganized into distinct modules to improve maintainability and clarity. A new \Maintenance\ module handles background tasks such as pruning dead processes and failing orphaned executions when a worker exits abnormally. Process identity is now managed by a dedicated \Pidfile\ class, integrated via the \Pidfiled\ concern to prevent duplicate supervisor instances. Signal handling has been extracted into a \Signals\ module, which manages graceful and immediate termination for standalone processes. These changes refactor existing behavior into separate files without altering the external API or operational logic of the supervisor.

_lib/solid\queue/supervisor · high confidence

The application's engine has been renamed from active\_job-database\_queue to solid\_queue. This change updates the engine path in bin/rails to point to the new lib/solid\_queue/engine directory, reflecting the rebranding of the underlying technology. Additionally, the bin/setup script now uses docker compose to start services and runs rails db:reset to ensure a clean database state before bundling dependencies.

bin · high confidence

The Solid Queue installation template has been replaced with a single \queue\_schema.rb\ file (version 1, targeting ActiveRecord 7.1) instead of individual migration files. This new schema introduces support for job batches by adding \solid\_queue\_batches\ and \solid\_queue\_batch\_executions\ tables, and includes a fix for the \job\_id\ foreign key column types in execution tables to ensure data integrity.

_lib/generators/solid\queue/install/templates/db · high confidence

Users can now schedule recurring jobs by providing a raw command string instead of a full job class. The new SolidQueue::RecurringJob executes the provided command string directly, enabling simpler task definitions for basic operations.

app/jobs · high confidence

Added integration tests for Puma plugin with Solid Queue; Added integration tests for Solid Queue process lifecycles and features; Added test coverage for SolidQueue models; Added test fixtures and configuration for Solid Queue dummy app; Added test helper jobs for Active Job features; Added test helpers for SolidQueue configuration, job execution, and process management; Added test support models for job execution and sharding; Added unit tests for Solid Queue core components and execution modes; Refactored test infrastructure and renamed test suite; Removed empty test placeholder file; Removed empty test/mailers placeholder; Test suite configuration updates for SolidQueue and SQLite; Updated dummy app environment configurations for Solid Queue testing; Updated test dummy database schemas for multi-shard and batch support.

The project now enforces Ruby 3.3 as the target version and adds RuboCop configuration via the rubocop-rails-omakase gem for standardized code style. Development and testing workflows are enhanced with Appraisals to support testing against Rails 7.1 through 8.1 (including main), a new Rakefile task to run tests across MySQL, PostgreSQL, and SQLite databases, and a docker-compose setup for local database services. Additionally, the repository's .gitignore has been expanded to exclude JetBrains IDE and VS Code settings, and the license file was updated to reflect 37signals ownership.

(repo-wide) · high confidence

The gem has been renamed from active\_job-database\_queue to solid\_queue, and its runtime dependencies now require Rails 7.1 or higher (activerecord, activejob, railties). The project also drops support for Ruby 3.1, raising the minimum requirement to Ruby 3.2, and adds specific dependencies for cron scheduling (fugit), concurrency (concurrent-ruby), and CLI tools (thor).

(dependencies) · high confidence

The gemfile test matrix has been updated to add support for testing against Rails versions 7.1, 7.2, 8.0, and 8.1, as well as the Rails main branch. This change expands the compatibility testing scope for the library, ensuring it functions correctly across these newer and upcoming Rails releases.

gemfiles · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• First survey — no prior run to compare against. CAI 55.

• Code Health 99
• Architecture 96
• Maturity 55
• Readiness 35
• Security 81
• Domain Modelling 100

• 300 commits — 272 feature/other, 28 fixes

• (root) — 99 commits
• lib/solid_queue — 78 commits
• app/models — 35 commits
• test/integration — 25 commits
• test/unit — 15 commits
• (repo) — 13 commits
• test/dummy — 11 commits
• .github/workflows — 6 commits
• lib/puma — 5 commits
• lib/solid_queue.rb — 3 commits
• test/models — 3 commits
• lib/generators — 2 commits
• test/test_helper.rb — 2 commits
• .devcontainer/devcontainer.json — 1 commit
• lib/active_job — 1 commit
• test/test_helpers — 1 commit

• fix: Corrects a minor bug in ScheduledExecution
• fix: Fix NoMethodError when status.exitstatus is nil
• fix: Fix README queues config value to array
• fix: Fix abstraction for RecurringSchedule and Process
• fix: Fix case where a recurring task key is empty in the config
• fix: Fix crash when recording a failed execution for a job that already has one
• fix: Fix devcontainer config
• fix: Fix empty? method in Scheduler::RecurringSchedule
• fix: Fix error class name in README.md
• fix: Fix flaky concurrency controls test
• fix: Fix flaky test for process recovery
• fix: Fix mismatches in readme
• fix: Fix names for public methods
• fix: Fix race condition between job enqueue and concurrency unblock
• fix: Fix recurring task double-enqueue caused by wall-clock race condition
• fix: Fix spacing
• fix: Fix style to match project conventions
• fix: Fix testing against Rails main
• fix: Fix undefined variable when replacing a failed thread
• fix: Fix: Detect and warn when schedules generate multiple CRONs (#707)
• …and 280 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

rails/solid_queue was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.