DEV Community: Shinichi Maeshima

SolidQueue now runs with multiple threads

Shinichi Maeshima — Fri, 23 Jan 2026 06:45:26 +0000

Recently, I’ve personally been using SolidQueue more and more as a background worker. Around that time, SolidQueue v1.3.0 was released, and it included a feature that I found particularly interesting, so I’d like to introduce it here.

Background

SolidQueue defines multiple roles:

Supervisor
Dispatcher
Scheduler
Worker

In the early days of SolidQueue, there was an async mode where each role could run as a thread within a single process.

However, in order to simplify the implementation, async mode was removed starting with v0.4.0, and SolidQueue began assigning one or more processes to each role.

SolidQueue Used More Memory Than Sidekiq

Because each role runs in its own process, even the minimum SolidQueue setup ends up spawning 3–4 processes (the Scheduler can be omitted if recurring jobs are not needed). Sidekiq, on the other hand, runs in a single process, so a server that works fine with Sidekiq can easily run into memory constraints when using SolidQueue.

I personally ran workers on Heroku using a 512 MB dyno, but when migrating from Sidekiq to SolidQueue, memory was no longer sufficient and I had no choice but to upgrade to a 1 GB dyno.

Rails is very convenient for individual developers because it can be easily deployed and operated on inexpensive VPSs. However, when using SolidQueue, a relatively larger amount of memory (around 2 GB or more) was required.

The Return of Async Mode

Due to this memory usage issue, some people started to want async mode to come back. Simply saying “we want to reduce memory usage” wasn’t enough to move things forward, but the discussion gained momentum when it became clear that people on JRuby and Windows—who couldn’t use SolidQueue because fork is unavailable—also wanted to be able to use it.

Eventually, the PR that brings back async mode was merged. This change is included in the recently released v1.3.0.

You can enable it by starting SolidQueue with bin/jobs --async or by setting SOLID_QUEUE_SUPERVISOR_MODE=async, which makes SolidQueue use threads instead of processes.

The README says the following, so using processes (fork) is generally more stable. Still, async mode seems quite convenient for limited environments such as personal projects.

The recommended and default mode is fork. Only use async if you know what you're doing and have strong reasons to.

In my own environment, memory usage dropped from over 600 MB to around 260 MB. Nice.

Released Gon v7.0.0

Shinichi Maeshima — Sun, 11 Jan 2026 06:29:04 +0000

I am a current maintainer of Gon. We have released Gon v7.0.0.

Release v7.0.0 · gazay/gon

As you can tell from the major version bump, this release includes breaking changes.
These breaking changes were introduced by the following PR created by @krororo:

Breaking: Make request_store an optional dependency by krororo · Pull Request #296 · gazay/gon

In gon, when you set a value like gon.foo = 'bar', the value used to be stored internally using request_store.
In the early days of Rails application development, request_store was almost the only practical option when you wanted to use a global value that was automatically reset for each request.

However, since Rails 5.2, Rails has provided an official alternative:
ActiveSupport::CurrentAttributes.

The PR above removes the dependency on request_store and switches gon to use ActiveSupport::CurrentAttributes instead.

Why this is good

I believe this change improves stability.

Currently, request_store uses Thread#[] internally.
As documented in the Thread#[] documentation, Thread#[] actually refers to fiber-local variables, which means the value cannot be accessed once execution switches to another Fiber.

Because of this, if your request-handling code uses Fibers, gon may behave incorrectly.

ActiveSupport::CurrentAttributes also initially relied on fiber-local variables when it was first introduced
(see this implementation).

However, starting with Rails 7.0, Rails can automatically switch between fiber-local and thread-local storage depending on the type of server being used
(see this commit by Shopify).

As a result, if you are using Rails 7.0 or later, ActiveSupport::CurrentAttributes should be more stable than request_store.
That is why we decided to merge this PR.

Concerns

Most users of gon probably don’t consciously think about whether it uses request_store or ActiveSupport::CurrentAttributes internally.

Given that, the new behavior is as follows:

If you are using Rails 5.2 or later and ActiveSupport::CurrentAttributes is available, gon will use it automatically.
Otherwise, you will need to explicitly add request_store to your Gemfile:

gem 'request_store'

I believe there are very few cases where you would want to explicitly use request_store with modern versions of Rails, which is why we made this decision.
That said, if you run into any issues, please let us know!

What is config.active_support.hash_digest_class = OpenSSL::Digest::SHA256?

Shinichi Maeshima — Tue, 26 Nov 2024 09:13:07 +0000

What is `config.active_support.hash_digest_class = OpenSSL::Digest::SHA256`?

I occasionally update the config.load_defaults version at work in Rails applications. This involves understanding the purpose of each new configuration in the target version, assessing its impact, and creating individual pull requests for each change. Based on my experience, this process can be quite challenging, and I suspect few projects carry it out with a thorough understanding of the impact. I decided to write this blog post to assist others planning to update config.load_defaults.

Today, I’ll focus on config.active_support.hash_digest_class = OpenSSL::Digest::SHA256, which is included in config.load_defaults 7.0.

Relevant Commit: Change the default digest for new apps to SHA256 · rails/rails@ba9207f
Related Documentation: Upgrading Ruby on Rails — Ruby on Rails Guides

This setting changes the default hash function used for cache keys to SHA256. The default was originally MD5, then updated to SHA1 in Rails 5.2, and now to SHA256 in Rails 7.0.

Since this hash function primarily applies to cache keys, the change wasn’t prompted by security issues with SHA1. Instead, the shift to SHA256 aligns Rails with modern security standards, simplifying compliance checks.

Related Areas in Rails

The following are the main areas in Rails where this hash function is used:

Determining keys for fragment cache templates
- Used to compute the template tree digest in the cache method.
Setting cache keys when using cache(User.all) with an ActiveRecord::Relation
- Specifically, it computes the id portion of the key.
Generating strong ETags
- Reference: Rails Caching Guide
Shortening long cache keys

You can safely apply this setting change if your project doesn’t rely on these caching features.

How to Verify Affected Areas

You can verify whether caching is used by adding a monkey patch like the following, which logs whenever ActiveSupport::Digest.hexdigest is called. This works for all related areas except "shortening long cache keys." Merge logs appropriately if your CI runs tests in parallel.

# config/application.rb or config/initializers/something.rb

module MonkeyPatch
  def monkeypatch_logger
    @monkeypatch_logger ||= Logger.new(Rails.root.join('log/monkeypatch.log'))
  end

  def hexdigest(*)
    monkeypatch_logger.debug("ActiveSupport::Digest.hexdigest is called from: #{caller(2, 1).first}")
    super
  end
end

class ActiveSupport::Digest
  class << self
    prepend MonkeyPatch
  end
end

Before running tests, enable caching and set the cache store to :null_store to avoid unexpected behavior:

# config/environments/test.rb
config.action_controller.perform_caching = true
config.cache_store = :null_store

If you find any areas using caching, note that this change will invalidate all related caches after deployment. This could increase server or database load, so consider temporarily scaling up your application servers and database resources to handle the extra traffic.

Summary of changes in behavior of create_association method in Rails 7.0.5 and later

Shinichi Maeshima — Tue, 04 Jul 2023 07:11:53 +0000

This article is an English translation from https://blog.willnet.in/entry/2023/07/04/113321

There are several related PRs and Issues on this matter and comments are scattered, and it is complicated to explain to people, so this is a summary as a blog. Please comment if you find any mistakes or opinions!

Update 2023/08/02

A commit has been made to revert this change to the 7-0-stable branch. It seems that the policy is to revert back and start over because some people had trouble with the new behavior.

[7-0-stable] Revert singular association breaking changes by zzak · Pull Request #48809 · rails/rails

I don't know when 7.0.7 will be released, but if it is released in its current state, it will revert to 7.0.4 behavior; those who are having trouble with changes after 7.0.5 may want to point to 7-0-stable once it is released.

Overview

Behavior of create_association method generated when defining has_one association is different in Rails 7.0.4 and 7.0.5 or later.
If you think that the behavior of create_association is only "create a new association record", you may need to modify your code to use 7.0.5 or later.

Assumptions

If you try to create a new model via has_one association when the association is already persisted, the existing association will be deleted(behavior of association= is written in http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#method-i-has_one but build_association and create_association do not seem to be described, including in the Rails guide).
The way the deletion is done depends on the dependent option of has_one (This is where the code is applicable. https://github.com/rails/rails/blob/89508b95d8d289b430cca7db05109d8171ff7a5f/activerecord/lib/active_record/associations/has_one_association.rb#L94-L116 )
- When :nullify or :dependent option is not set, set NULL to the foreign key and UPDATE
- When :delete, delete with the destroy method
- When :delete, delete with delete method.

For example, in all of (1)~(3) in the following code, if there is a record associated with an existing associate, it will be deleted.

class User < ApplicationRecord
  has_one :address, dependent: :destroy
end

class Address
  belongs_to :user
end

user = User.find(42)
user.address = Address.new # (1)
user.create_address # (2)
user.build_address # (3)

Behavior up to Rails 7.0.4

Previously, the behavior of create_association was to insert and then delete in separate transactions as described in this PR.

# begin transaction
INSERT new_record; # commit transaction
# commit transaction

# begin transaction
DELETE old_record; # commit transaction
# commit transaction

Furthermore, even if the preceding insert (save method) fails due to a validation error, the subsequent delete will still be executed. This behavior caused a bug in which a validation error would result in the deletion of an existing record when execute create_association!

There was another issue where deletion of existing records did not work in the following way

create a new record when the validation passes
then delete the existing record
retrieving an existing record for deletion is done via has_one related method.
when the order by related to has_one is not set (in most cases, order by is not set for has_one), the newly created record is retrieved in rare cases.
if this newly created record is retrieved, it is treated as if there are no records to delete
as a result, there are two or more records without deletion.

Behavior since Rails 7.0.5

In 7.0.5, the behavior has changed to delete and then insert in the same transaction, as shown below, and the above bug has been mostly resolved.

# begin transaction
DELETE old_record;
INSERT new_record; # commit transaction
# commit transaction

However, the code would need to be modified for an application that originally had a unique constraint on the has_one foreign key and wanted to make a validation error if create_association was performed when there was an existing record.

Thoughts

I personally feel that the changes in 7.0.5 were necessary for the consistency of the behavior described in the "Assumptions" section, but on the other hand, I understand that it may be surprising to people who do not know that association=, build_association, or create_association will delete existing records. On the other hand, I can understand why some people might find it hard to modify their code to accommodate this change, as it might be a surprise to those who are not familiar with this behavior.

I wonder what kind of behavior would make everyone happy...?