Sidekiq Scheduled Jobs Stopped Running After a Gemfile Update
After updating my Gemfile to fix a Rails boot error, Sidekiq scheduled jobs silently stopped running despite the process and queues looking healthy. The root cause turned out to be a gem incompatibility that crashed Sidekiq’s scheduler thread on boot, reinforcing the importance of reading errors before changing everything else.
Encountering the Problem
Doing my day to day work I stumbled upon:
1
2
3
4
5
6
7
8
> rails s
<internal:/usr/share/rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require': cannot load such file -- rails/cli (LoadError)
from <internal:/usr/share/rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
from /usr/share/rvm/gems/ruby-3.2.2/gems/railties-7.2.2.2/exe/rails:10:in `<top (required)>'
from /usr/share/rvm/gems/ruby-3.2.2/bin/rails:25:in `load'
from /usr/share/rvm/gems/ruby-3.2.2/bin/rails:25:in `<main>'
from /usr/share/rvm/gems/ruby-3.2.2/bin/ruby_executable_hooks:22:in `eval'
from /usr/share/rvm/gems/ruby-3.2.2/bin/ruby_executable_hooks:22:in `<main>'
So what I did to fix this was to rm Gemfile.lock and reinstall it with bundle install. What this did was update a looot of things, but it got my Rails working.
Stumbling Upon a Second Problem
Fast forward a bit and my job scheduling stopped working. I tried changing every configuration, configuring redis on my local machine, reading a lot about sidekiq, and other unrelated stuff… Nothing seemed to work.
What I missed doing was reading the error that appeared every time I ran bundle exec sidekiq. I kind of ignored it.
1
2
3
4
5
6
7
8
9
2026-02-02T13:51:37.604Z pid=46208 tid=1a8s WARN: {"context":"scheduler"}
2026-02-02T13:51:37.604Z pid=46208 tid=1a8s WARN: ArgumentError: wrong number of arguments (given 1, expected 0)
2026-02-02T13:51:37.604Z pid=46208 tid=1a8s WARN:
#<Thread:0x00007472c2fe1380@sidekiq.scheduler /usr/share/rvm/gems/ruby-3.2.2/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:17 run> terminated with exception (report_on_exception is true):
/usr/share/rvm/gems/ruby-3.2.2/gems/connection_pool-3.0.2/lib/connection_pool/timed_stack.rb:62:in `pop': wrong number of arguments (given 1, expected 0) (ArgumentError)
from /usr/share/rvm/gems/ruby-3.2.2/gems/sidekiq-7.3.9/lib/sidekiq/scheduled.rb:226:in `initial_wait'
from /usr/share/rvm/gems/ruby-3.2.2/gems/sidekiq-7.3.9/lib/sidekiq/scheduled.rb:96:in `block in start'
from /usr/share/rvm/gems/ruby-3.2.2/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:10:in `watchdog'
from /usr/share/rvm/gems/ruby-3.2.2/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:19:in `block in safe_thread'
What Chatgpt said:
1
2
3
4
5
6
Your Sidekiq scheduler thread is crashing on boot.
When that thread dies, scheduled jobs will never be promoted. Sidekiq keeps running, queues look fine, but scheduled jobs are dead forever.
This is a known incompatibility between:
Sidekiq 7.3.9
connection_pool 3.0.2
Sooo what really happened was that my HUGE Gemfile update messed things up.
The Solution
I reverted my whole Gemfile mess and got back to the start with the error of Rails not working.
So I ran Rails with bundle exec rails.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
bundle exec rails
/usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/runtime.rb:304:in `check_for_activated_spec!': You have already activated uri 1.1.1, but your Gemfile requires uri 1.0.3. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/runtime.rb:25:in `block in setup'
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/spec_set.rb:165:in `each'
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/spec_set.rb:165:in `each'
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/runtime.rb:24:in `map'
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/runtime.rb:24:in `setup'
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler.rb:162:in `setup'
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/setup.rb:10:in `block in <top (required)>'
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/ui/shell.rb:159:in `with_level'
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/ui/shell.rb:111:in `silence'
from /usr/share/rvm/gems/ruby-3.2.2/gems/bundler-2.4.19/lib/bundler/setup.rb:10:in `<top (required)>'
from <internal:/usr/share/rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
from <internal:/usr/share/rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
from /usr/share/rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems.rb:1370:in `<top (required)>'
from <internal:gem_prelude>:2:in `require'
from <internal:gem_prelude>:2:in `<internal:gem_prelude>'
Aha! The exact error. So instead of updating all of the gems, what I really needed to do is fix only the uri gem.
1
2
3
4
5
6
# Gemfile
# Because of: "already activated uri 1.1.1, but your Gemfile requires uri 1.0.3"
# Ruby 3.2 ships with uri as a default gem (v1.1.1).
# Our Gemfile (or a dependency) is pinning uri 1.0.3.
gem "uri", "~> 1.1"
I am also leaving a comment inside so we know what happened and why we are setting it to this specific version.
Conclusion
If I read the error from the very beggining, instead of rushing to fix unrelated stuff, it would have been way faster.
We learn something new every day ig. Long live the senior developers.