Missing constant error in puma

[travisofthenorth]

Getting this error intermittently in a threaded puma server:
Internal Server Error: uninitialized constant JsonApiClient::DasherizedKeyFormatter

I am guessing that the issue here is similar to rack/rack-attack#229, i.e. the use of autoload in the gem isn't thread-safe and is ultimately the cause of the exception.

Any particular reason the gem uses autoloading instead of just requiring related files? Can that be changed safely/easily?

[travisofthenorth]

I think this is the PR on their side that resolved the issue: rack/rack-attack#314

[travisofthenorth]

Also, FWIW this does not seem to happen on 1.5.3. It only started happening on the latest version (1.9)

[gaorlov]

Can you tell me a little bit more about your setup so i can repro it?

[travisofthenorth]

MRI ruby 2.5.3p105
rails 5.2.2.1
puma 3.12.0
json_api_client 1.9.0

@gaorlov Do you need any other info?

[gaorlov]

Can you give a bit more details on how you're booting the server or if you have init configs that reference json api client? I cannot seem to repro a vanilla puma app with the 1.9.0 client in dev or production modes.

[travisofthenorth]

Looks like the only configs we specify are thread count and port, so we're using defaults for workers, preloading, etc.

Upon retesting it, it looks like the problem only manifests when a json_api_client object is loaded from cache, i.e. using Rails.cache.fetch. When starting with an empty cache, it doesn't seem to be a problem.

[yuri-val]

Looks like the only configs we specify are thread count and port, so we're using defaults for workers, preloading, etc.

Upon retesting it, it looks like the problem only manifests when a json_api_client object is loaded from cache, i.e. using Rails.cache.fetch. When starting with an empty cache, it doesn't seem to be a problem.

@travisofthenorth Also got this proplem.
it seems that this constant is initialized at the time of the first call to the class JsonApiClient::Resource and if you fetch it from chache it's not initialized.
My workaround - adding follow code to application.rb:

# Require this cause got an error while fetch it from cache
# NameError: uninitialized constant JsonApiClient::UnderscoredKeyFormatter
require 'json_api_client'
JsonApiClient::Resource.new

[kamal]

I just hit this. I don't think it has anything to do with being thread-safe or not. In a brand new rails app with the json_api_client gem running rails console (development or production, doesn't matter), I can hit the exception

irb(main):001:0> JsonApiClient::KeyFormatter
Traceback (most recent call last):
        1: from (irb):1
NameError (uninitialized constant JsonApiClient::KeyFormatter)

If I then do irb(main):001:0> JsonApiClient::Formatter, autoload kicks in and now JsonApiClient::KeyFormatter will work.

Given a class hierarchy that looks like

JsonApiClient::Formatter
  +-> JsonApiClient::KeyFormatter
        +-> JsonApiClient::UnderscoredKeyFormatter

is the expected behavior of directly accessing JsonApiClient::UnderscoredKeyFormatter to try to resolve JsonApiClient::KeyFormatter, which then tries to resolve JsonApiClient::Formatter and then hoping autoload will kick in here? Does it matter if JsonApiClient::Formatter exists only as a class, and not a module? Does it affect things that all of the formatters are defined in a single file?