Delay initialization until Rails is fully initialized

[DmitryTsepelev]

Related to the Zeitwerk issue about occasional NameError inside Sidekiq

In some cases sidekiq-grouping starts before Rails is fully initialized and Zeitwerk initial loading is completed, which can cause situations when some classes are loaded inside the concurrent thread rather than in Zeitwerk. This PR moves gem initialization to the Railtie.

[DmitryTsepelev]

Moved this section to the top because non-Rails users will have to perform an extra setup

[DmitryTsepelev]

This is a breaking change, so I guess we'll need a major release

[MrPhantomT]

Hi there are there any plans to merge this pull-request?

[jgoerz-ehub]

We had a similar problem. In our case, the sidekiq-grouping initialization would clobber our redis URL initialization forcing the use of the default redis URL (localhost) which didn't work for our production setup. The workaround is to properly sequence the initialization. In rails, this can be done by:

# config/initializers/sidekiq.rb

# The gem runs `Sidekiq::Grouping.start!` at require time (whenever Sidekiq.server? is true),
# spawning a background poller. Requiring it here, inside after_initialize, i.e. after all
# initializers, eager loading and Zeitwerk have finished,  mirrors upstream PR #41
# (https://github.com/gzigzigzeo/sidekiq-grouping/pull/41), which is neither merged nor
# released. Deferring the poller this late guarantees Sidekiq's Redis URL is already set,
# so it builds the internal connection pool against the real Redis instead of
# memoizing the localhost fallback, and it avoids the poller autoloading app classes off
# the main thread before eager load.
Rails.application.config.after_initialize do
  require 'sidekiq/grouping'
end

And

# Gemfile
gem 'sidekiq-grouping', require: false