Puma plugin fails with NameError

[MrSerth]

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

[rosa]

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?

[MrSerth]

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.

[rosa]

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]

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