rails: LoadError when multiple threads try to load the same namespaced class

An other workaround that works for us was to only use one thread in development to keep the eager_load = false.

# config/puma/development.rb
workers 1
threads 1, 1

• Rails 5.0.7.2
• Ruby 2.6.6
• Puma 4.3.5

Ha! Yes, you are correct. That’s what I get for trying to be funny - my actual tests were using A and A::B, which is harder to mess up 😃

The issue still stands, so I updated the original post, thanks.

I’ve encountered the same issue on the project I’m working on. After some investigation I found the following. If we take this code as an example

# controllers/invoices_controller.rb
class InvoicesController < ApplicationController
  Billing::Invoice 
end

# models/billing/invoice.rb
module Billing
  class Invoice
  end
end

The process of loading Billing::Invoice constant can be described by following pseudocode:

1. load const Billing (it is not resolved by ruby so it has to be autoloaded) 1.1. check if file billing.rb exists in autoload paths 1.2. check if directory billing exists in autoload paths (it does) 1.2.1. create module Billing
2. load const Invoice 2.1. check if file billing/invoice.rb exists in autoload paths (it does) 2.1.1. load/require the file billing/invoice.rb 2.1.2. check if the constant Invoice is now defined on the Billing module and raise LoadError error if not

The issue with concurrent execution arises on step 1.2.1 as the code which creates “automatic” modules is not thread safe. See autoload_module! method

def autoload_module!(into, const_name, qualified_name, path_suffix)
  return nil unless base_path = autoloadable_module?(path_suffix)
  mod = Module.new
  into.const_set const_name, mod
  autoloaded_constants << qualified_name unless autoload_once_paths.include?(base_path)
  autoloaded_constants.uniq!
  mod
end

Rails does not check if the module is already defined and does not synchronise access to this method which in turn results in multiple instances of Billing module being created. On each of those instances the const_missing method is later invoked (in step 2) for the constant Invoice. The code that loads the Invoice constant is thread safe (see load_missing_constant and require_or_load methods) and loads the Invoice constant only once. The Invoice constant is then saved in the constants table of one of created Billing modules, but step 2.1.2 is invoked for each of them resulting in the LoadError error being raised.

It seems that the issue can be solved by simply making autoload_module! method thread safe. I’ve experimented with this solution and it appears to have resolved the issue.

I had to disable wrap_parameters as a workaround