Custom rufus_scheduler_options does not take into effect during runtime when dynamic: true

[Shayon Mukherjee]

Problem

When you set a custom option like the following for rufus scheduler, it does not take into effect during runtime.

SidekiqScheduler::Scheduler.instance.rufus_scheduler_options = { max_work_threads: 5 }

Readme: https://github.com/moove-it/sidekiq-scheduler#notes-about-connection-pooling

How / Why

In a rails like application, this is primarily since gems are initialized first. So sidekiq-scheduler's sidekiq startup hook gets defined first - https://github.com/moove-it/sidekiq-scheduler/blob/41990aafa80a0f458e988733189fbf4b07e0894a/lib/sidekiq-scheduler.rb#L12

The startup hook/event calls the start function https://github.com/moove-it/sidekiq-scheduler/blob/41990aafa80a0f458e988733189fbf4b07e0894a/lib/sidekiq-scheduler.rb#L18

Which ends up calling the load_schedule! function and ultimately the memoized rufus_scheduler instance variable here when dynamic is set to true in the config options.

Since during application boot time @rufus_scheduler is already instantiated, setting a custom SidekiqScheduler::Scheduler.instance.rufus_scheduler_options (getter/setterhttps://github.com/moove-it/sidekiq-scheduler/blob/51fc23863317e11fde57678be985398b0aa2f8be/lib/sidekiq-scheduler/scheduler.rb#L76) from the application's initializer or the application's own sidekiq startup hook does take into effect anymore.

So, since the gems is loaded and initialized first, sidekiq-scheduler's `startup hook get registered to Sidekiq and then any other application specific startup hooks get registered, and accordingly played.

How to replicate

In a rails application inside

Sidekiq.configure_server do |config|
...
  config.on(:startup) do
    SidekiqScheduler::Scheduler.instance.rufus_scheduler_options = { max_work_threads: 5 }

    Rails.logger.info(SidekiqScheduler::Scheduler.instance.rufus_scheduler.max_work_threads)
  end
...
end

Or in a rails console

 SidekiqScheduler::Scheduler.instance.rufus_scheduler.max_work_threads
=> 28 # default
irb(main):003:0> SidekiqScheduler::Scheduler.instance.rufus_scheduler_options = { max_work_threads: 5 }
=> {:max_work_threads=>5}
irb(main):004:0> SidekiqScheduler::Scheduler.instance.rufus_scheduler.max_work_threads
=> 28

Rails version: 6.1.1
Sidekiq version: 6.4.1
Sidekiq-scheduler version: 3.1.1

Potential solution

To avoid having to change the order of initializer or how/when the startup hook is registered. It'd be perhaps simpler to move rufus_scheduler_options as a configuration option (Readme), such that the options are registered and initialized with proper during startup (here) by sidekiq-scheduler itself.

https://github.com/moove-it/sidekiq-scheduler/blob/41990aafa80a0f458e988733189fbf4b07e0894a/lib/sidekiq-scheduler.rb#L16