solid_queue
solid_queue copied to clipboard
Puma plugin fails with `NameError`
We've just integrated solid_queue in our Rails app and want to use the puma plugin to run Solid Queue's supervisor. However, with our current puma config, this fails:
/.rvm/gems/ruby-3.3.2/gems/solid_queue-0.3.3/lib/puma/plugin/solid_queue.rb:13:in `block (2 levels) in start': uninitialized constant SolidQueue (NameError)
SolidQueue::Supervisor.start(mode: :all)
^^^^^^^^^^
from /.rvm/gems/ruby-3.3.2/gems/solid_queue-0.3.3/lib/puma/plugin/solid_queue.rb:11:in `fork'
from /.rvm/gems/ruby-3.3.2/gems/solid_queue-0.3.3/lib/puma/plugin/solid_queue.rb:11:in `block in start'
from /.rvm/gems/ruby-3.3.2/gems/puma-6.4.2/lib/puma/events.rb:17:in `block in fire'
from /.rvm/gems/ruby-3.3.2/gems/puma-6.4.2/lib/puma/events.rb:17:in `each'
from /.rvm/gems/ruby-3.3.2/gems/puma-6.4.2/lib/puma/events.rb:17:in `fire'
from /.rvm/gems/ruby-3.3.2/gems/puma-6.4.2/lib/puma/events.rb:46:in `fire_on_booted!'
from /.rvm/gems/ruby-3.3.2/gems/puma-6.4.2/lib/puma/cluster.rb:495:in `run'
from /.rvm/gems/ruby-3.3.2/gems/puma-6.4.2/lib/puma/launcher.rb:194:in `run'
from /.rvm/gems/ruby-3.3.2/gems/puma-6.4.2/lib/puma/cli.rb:75:in `run'
from /.rvm/gems/ruby-3.3.2/gems/puma-6.4.2/bin/puma:10:in `<top (required)>'
from /.rvm/gems/ruby-3.3.2/bin/puma:25:in `load'
from /.rvm/gems/ruby-3.3.2/bin/puma:25:in `<main>'
from /.rvm/gems/ruby-3.3.2/bin/ruby_executable_hooks:22:in `eval'
from /.rvm/gems/ruby-3.3.2/bin/ruby_executable_hooks:22:in `<main>'
[95129] ! reaped unknown child process pid=95143 status=pid 95143 exit 1
I've reduced our puma.rb config and also reproduced the issue with a new Rails app.
Steps to reproduce:
- Create a new Rails app:
rails new "solid_queue" -T --api --no-tests - Add the gem to the Gemfile
gem "solid_queue" - Run
bundle install - Install with
rails generate solid_queue:install - Migrate with
rails db:migrate - Modify the
puma.rbconfig: a. Configureworkersto be used, i.e.workers 2b. Addpreload_app! falsec. Add the puma plugin withplugin :solid_queue - Start the app through Puma with
bundle exec puma - ⚡️ See the above name error.
Even without starting the app through puma, I was able to reproduce the error with the following steps:
Steps to reproduce:
- Create a new Rails app:
rails new "solid_queue" -T --api --no-tests - Add the gem to the Gemfile
gem "solid_queue" - Run
bundle install - Install with
rails generate solid_queue:install - Migrate with
rails db:migrate - Modify the
puma.rbconfig: a. Configureworkersto be used, i.e.workers 2b. Addprune_bundlerc. Add the puma plugin withplugin :solid_queue - Start the app regularly through
rails s - ⚡️ See the above name error.
In our production environment, we use a combination of the puma command with preload_app! false ("replaced" by fork_worker) and prune_bundler for phased restarts. Obviously, this configuration isn't supported by the puma plugin.
Ruby: 3.3.2 +YJIT Rails: 7.1.3.4 Puma: 6.4.2 Solid Queue: 0.3.3
Even without starting the app through puma, I was able to reproduce the error with the following steps:
Do you mean without using the Solid Queue plugin at all? It just fails when you try to start the app via rails s?
Sorry for not being clear on this. In the original issue report, I provided two different lists of reproduction steps for this issue:
- The first list contains a combination of puma settings that is problematic when the web server is started through
bundle exec pumabut not when it is started withbundle exec rails s. - The second list of reproduction steps shows the erroneous behavior either with
bundle exec pumaorbundle exec rails s.
Even without starting the app through
puma, I was able to reproduce the error with the following steps:
Here, I wanted to highlight that the second list does not require bundle exec puma (as a command), but also shows the erroneous behavior when starting through bundle exec rails s.
In any case, the puma plugin is required to reproduce the issue. Without the Solid Queue plugin for Puma, the error does not occur. Since the Puma plugin is going to be removed with #303, this issue is obsolete and can be closed.
Ah, got it! Sorry, I misunderstood what you meant! 🙏 Thanks a lot for taking the time to clarify. And yes, it's true that with the Puma plugin going away, the issue is no longer applicable. Thanks again.
Like with #243, we're going to keep the plugin in the end, so I'll reopen. Thanks again for your patience!
I've documented this limitation in the README (https://github.com/rails/solid_queue/commit/0fb714413c474b4b649fe87bd17d08896f9666a9) because I won't be able to work on it in the near (and medium-term) future 😓 But if anyone wants to work on it, I'll be happy to review and test.
Thanks for pointing that out in the Readme! I totally understand you need to focus, and assuming the simplest puma setup is valid for a majority of apps, I would assume. Just a minor remark: The link for the commit is not working as expected, because it ends with 6a99, but should only end in 6a9.
Oops, I totally fat-fingered that 🤦♀ Sorry and thanks for letting me know, and for your understanding! ❤