solid_queue icon indicating copy to clipboard operation
solid_queue copied to clipboard

Puma plugin fails with `NameError`

Open MrSerth opened this issue 1 year ago • 4 comments

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:

  1. Create a new Rails app: rails new "solid_queue" -T --api --no-tests
  2. Add the gem to the Gemfile gem "solid_queue"
  3. Run bundle install
  4. Install with rails generate solid_queue:install
  5. Migrate with rails db:migrate
  6. Modify the puma.rb config: a. Configure workers to be used, i.e. workers 2 b. Add preload_app! false c. Add the puma plugin with plugin :solid_queue
  7. Start the app through Puma with bundle exec puma
  8. ⚡️ 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:

  1. Create a new Rails app: rails new "solid_queue" -T --api --no-tests
  2. Add the gem to the Gemfile gem "solid_queue"
  3. Run bundle install
  4. Install with rails generate solid_queue:install
  5. Migrate with rails db:migrate
  6. Modify the puma.rb config: a. Configure workers to be used, i.e. workers 2 b. Add prune_bundler c. Add the puma plugin with plugin :solid_queue
  7. Start the app regularly through rails s
  8. ⚡️ 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

MrSerth avatar Jun 12 '24 20:06 MrSerth

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?

rosa avatar Aug 24 '24 20:08 rosa

Sorry for not being clear on this. In the original issue report, I provided two different lists of reproduction steps for this issue:

  1. The first list contains a combination of puma settings that is problematic when the web server is started through bundle exec puma but not when it is started with bundle exec rails s.
  2. The second list of reproduction steps shows the erroneous behavior either with bundle exec puma or bundle 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.

MrSerth avatar Aug 25 '24 09:08 MrSerth

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.

rosa avatar Aug 25 '24 17:08 rosa

Like with #243, we're going to keep the plugin in the end, so I'll reopen. Thanks again for your patience!

rosa avatar Sep 05 '24 20:09 rosa

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.

rosa avatar Jun 17 '25 07:06 rosa

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.

MrSerth avatar Jun 17 '25 07:06 MrSerth

Oops, I totally fat-fingered that 🤦‍♀ Sorry and thanks for letting me know, and for your understanding! ❤

rosa avatar Jun 17 '25 07:06 rosa