Glonce

Solid Queue 1.6.0 adds fiber workers for Rails background jobs

toolsThe Glonce editorsHacker News🔥61Glonce rating61Impact55Novelty60Relevance80Surprise40Players45Credibility88
Solid Queue 1.6.0 adds fiber workers for Rails background jobs

Solid Queue, the background job library bundled with Rails, shipped version 1.6.0 with a new fiber-based worker execution mode. Previously, a worker processed jobs using a thread pool: a fixed number of OS threads, each handling one job at a time. The new mode instead runs many fibers on a single fiber reactor thread. A worker switches to fiber mode by replacing the threads setting with a fibers count in its configuration, for example fibers: 100 with polling_interval: 0.05. The feature depends on the Async gem, which must be present for fiber mode to work, and requires fiber isolation to be turned on in Rails via config.active_support.isolation_level = :fiber. The release notes describe fiber workers as useful for I/O-bound workloads, citing calls to LLMs as an example: a fiber yields control while waiting on network I/O instead of blocking an entire thread, so a single reactor thread can juggle far more concurrent waits than a thread pool of the same size. The fiber worker mode itself was contributed by a first-time contributor, crmne, in pull request #728. Two smaller fixes shipped in the same release: rosa fixed transactions leaked by killed job threads during tests (#773), and another first-time contributor, wintan1418, documented how to update dynamic recurring tasks (#777). The full set of changes is listed against the previous release, v1.5.1, in the project's changelog.

Key facts

  • Solid Queue 1.6.0 adds a fiber-based worker mode as an alternative to the existing thread-pool mode.
  • Workers switch to it by setting a fibers count (example: fibers: 100) and a polling_interval (example: 0.05) instead of a thread count.
  • The mode requires the Async gem as a dependency and Rails fiber isolation enabled via config.active_support.isolation_level = :fiber.
  • The release notes describe it as well suited to I/O-bound workloads such as LLM calls.
  • The fiber worker feature was contributed by first-time contributor crmne in PR #728; the same release also fixed leaked test transactions (rosa, #773) and documented updating dynamic recurring tasks (wintan1418, #777).

Why it matters

Background job systems built on OS threads hit a ceiling when jobs spend most of their time waiting on network calls rather than computing, because each waiting thread still holds system resources. Fibers are lightweight, cooperatively scheduled units that yield during I/O waits, so a single reactor thread can hold far more of them concurrently than a thread pool could hold threads. Solid Queue is bundled with Rails as its default job backend, so this option becomes broadly available across the Rails ecosystem rather than sitting in a niche library.

Who it affects

Rails application developers who run Solid Queue for background jobs, particularly those whose jobs are dominated by waiting on external services rather than local computation. The release notes single out jobs that call LLMs as a fitting case, since those calls are typically slow, network-bound requests that leave a worker thread idle while waiting for a response.

How to use it

A worker opts into fiber mode by editing its configuration to specify a fibers count and a polling_interval instead of a threads count, as in the example workers entry (queues: "api*", fibers: 100, polling_interval: 0.05). Two additional prerequisites apply: the Async gem must be a dependency of the application, and Rails must have fiber isolation enabled through config.active_support.isolation_level = :fiber. No pricing or licensing terms are mentioned since Solid Queue is an open-source Rails component.

How solid is it

The information comes directly from the official GitHub release notes for v1.6.0, which name the contributing pull requests (#728, #773, #777) and the changelog range (v1.5.1...v1.6.0). The release notes do not include benchmarks or throughput comparisons between fiber mode and thread-pool mode, nor do they specify which Rails or Ruby versions are required to use fiber workers.

Risks and caveats

The feature carries real setup requirements: it will not work without the Async gem present and without fiber isolation explicitly turned on in the Rails configuration, so it is not a drop-in default. No data is given on how fiber mode behaves under CPU-bound jobs, where its I/O-oriented design would not offer the same advantage, and no migration guidance beyond the configuration swap is provided in the release notes.

“This can be very useful for I/O-bound workloads, such as those involving LLM calls.”

— Solid Queue 1.6.0 release notes