“Why does Redis-Rails deploy fail with `Unable to load application: LoadError: cannot load such file — fiber`?”

TLDR; I’m running a Rails app on Heroku. I have staging & production environments, set up as 2 apps in a pipeline. As the heroku stack heroku-18 has reached EOL, I’m in the process of upgrading the app to heroku-22. Upgrading staging worked perfectly fine, but on production I’m getting the following error: Unable to load application: LoadError: cannot load such file -- fiber

Note that my app is set up with 2 processes:

• web.1: web server running rails with puma
• worker.1: worker running sidekiq

Both processes crash every time I attempt to deploy. web.1:

heroku[web.1]: Starting process with command `bundle exec puma -p 11167`
app[web.1]: [2] Puma starting in cluster mode...
app[web.1]: [2] * Puma version: 6.2.2 (ruby 3.2.2-p53) ("Speaking of Now")
app[web.1]: [2] *  Min threads: 5
app[web.1]: [2] *  Max threads: 5
app[web.1]: [2] *  Environment: production
app[web.1]: [2] *   Master PID: 2
app[web.1]: [2] *      Workers: 2
app[web.1]: [2] *     Restarts: (✔) hot (✖) phased
app[web.1]: [2] * Preloading application
app[web.1]: [2] ! Unable to load application: LoadError: cannot load such file -- fiber
app[web.1]: bundler: failed to load command: puma (/app/vendor/bundle/ruby/3.2.0/bin/puma)
app[web.1]: <internal:/app/vendor/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require': cannot load such file -- fiber (LoadError)
app[web.1]: from <internal:/app/vendor/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
app[web.1]: from /app/vendor/bundle/ruby/3.2.0/gems/zeitwerk-2.6.8/lib/zeitwerk/kernel.rb:38:in `require'
app[web.1]: from /app/vendor/bundle/ruby/3.2.0/gems/actionview-7.0.4.3/lib/action_view/renderer/streaming_template_renderer.rb:3:in `<top (required)>'
...

And worker.1:

heroku[worker.1]: Starting process with command `bundle exec sidekiq`
heroku[worker.1]: State changed from starting to up
app[worker.1]: 2 TID-398 INFO: Booting Sidekiq 4.0.2 with redis options {:url=>"REDACTED", :ssl_params=>{:verify_mode=>0}}
app[worker.1]: bundler: failed to load command: sidekiq (/app/vendor/bundle/ruby/3.2.0/bin/sidekiq)
app[worker.1]: <internal:/app/vendor/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require': cannot load such file -- fiber (LoadError)
app[worker.1]: from <internal:/app/vendor/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
app[worker.1]: from /app/vendor/bundle/ruby/3.2.0/gems/zeitwerk-2.6.8/lib/zeitwerk/kernel.rb:38:in `require'
app[worker.1]: from /app/vendor/bundle/ruby/3.2.0/gems/actionview-7.0.4.3/lib/action_view/renderer/streaming_template_renderer.rb:3:in `<top (required)>'
...

Environment details:

• ruby 3.2.2
• rails 7.0.4.3
• puma 6.2.2
• sidekiq 4.0.2 (haven’t gotten around to upgrading this one but shouldn’t affect web.1)
• Staging and production environments are very similar. They use the same gems except for newrelic_rpm (production only), which isn’t anywhere in the crash stack trace. They have almost identical resources in heroku in terms of dynos and db types and so on.

The fact that both processes are crashing makes me think there’s something wrong that is unrelated to the puma or sidekiq configurations. The fact that both run fine on staging has me baffled.

I first upgrading the staging environment using the heroku CLI to set the stack to heroku-22, and then deploying the latest version of the codebase (this included the new ruby version, new rails version, and may other gem and code updates). Then, I tried the following (rolling back to last working version after every deploy attempt ended in crash):

• Promoting the staging app to production (a heroku pipeline feature).
• Upgrading production stack from CLI, then deploying manually (not using pipeline).
• Contacting Heroku customer support.
• Setting HEROKU_DEBUG_RAILS_RUNNER=1 (suggested by Heroku CS), which did not produce any additional messages.
• Restarting dynos right after a failed deploy.
• Scaling dynos to 0, then deploying, then scaling back up.