Rails 8, Solid Queue on macOS (former OS X)

The Good, Bad and Ugly

A few weeks ago, I started a new Rails project. Since this was a brand new project, I decided to move away from Sidekiq and GoodJob (which I’ve been using in the past) and try something more aligned with Rails 8 and above: Solid Queue so that everything fits in Postgres.

Image generated using Meta AI

The initial configuration seemed pretty straightforward, but I quickly ran into several challenges. The documentation wasn’t entirely accurate and contained outdated information, such as references to rails db:migrate:queue — a command that simply doesn't work since the migration is no longer created by the install command rails solid_queue:install.

It turns out the team decided that when you’re using separate tables, you should use the rails db:schema:load:queue command instead, as it's more efficient.

After ensuring that:

1. My database.yml was correctly configured to support the tables needed by queue, cache, and cable
2. My cable configuration was properly set up:

development:
  # adapter: async # removed as we are using solid_queue
  adapter: solid_cable
  ...

I thought I was ready to go. With confidence, I triggered ./bin/dev, only to experience the biggest crash of the day:

…/gems/pg-1.5.9/lib/pg/connection.rb:837: 
[BUG] Segmentation fault at 0x0000000128700b04 
ruby 3.3.3 (2024–06–12 revision f1c7b6f435) [arm64-darwin23]

Ouch!

Get Stéphane Paquet’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

After spending time recompiling different versions of the pg gem and searching around, I eventually found a helpful GitHub issue: https://github.com/rails/solid_queue/issues/407 that pointed me in the right direction.

The solution involved two key changes:

First, I edited the puma.rb file to ensure that in the development environment, Solid Queue runs on the same thread as the server:

plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"] || Rails.env.development?

Second, I added a “magic” parameter to the Procfile to ensure that Solid Queue can properly fork when needed on macOS:

web: env RUBY_DEBUG_OPEN=true OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES bin/rails server
js: bun run build --watch
css: yarn build:css --watch

And voilà! Everything worked perfectly.

This experience highlights the growing pains that come with adopting new Rails features early. While Solid Queue shows great promise for simplifying background job processing in Rails 8, the documentation and macOS compatibility still need some refinement. Despite these initial hurdles, I’m excited about the potential of this built-in solution and look forward to seeing how it evolves.

Updates:

After longer search and analysis, the issue seems to arise when the following configuration is used (either in developmment.rb, production.rb, test.rb or application.rb):

# Solid Queue configuration.
config.active_job.queue_adapter = :solid_queue
config.solid_queue.connects_to = { database: { writing: :queue } }