Skip to content

Background worker default retry settings not being used in production for a few workers

We've noticed that ReactiveCachingWorker and ExternalServiceCachingWorker have this sidekiq config locally:

[1] pry(main)> ExternalServiceReactiveCachingWorker.get_sidekiq_options
=> {"retry"=>3, "queue"=>"external_service_reactive_caching", :backtrace=>true}

[2] pry(main)> ReactiveCachingWorker.get_sidekiq_options
=> {"retry"=>3, "queue"=>"reactive_caching", :backtrace=>true}

For comparison, that's the same of MergeWorker:

[1] pry(main)> MergeWorker.get_sidekiq_options
=> {"retry"=>3, "queue"=>"merge", :backtrace=>true}

Which is expected, considering we set these upon Sidekiq initialization.

But if we look prods config, this setting is apparently missed and true is set (and it's not the case for the MergeWorker).

[ gprd ] production> ExternalServiceReactiveCachingWorker.get_sidekiq_options
=> {"retry"=>true, "queue"=>"external_service_reactive_caching"}

[ gprd ] production> ReactiveCachingWorker.get_sidekiq_options
=> {"retry"=>true, "queue"=>"reactive_caching"}

[ gprd ] production> MergeWorker.get_sidekiq_options
=> {"retry"=>3, "queue"=>"merge"}

Which can lead up to 20 failure retries.

The current suspicions are that the fact the ApplicationWorker is included through a included call (in a concern) might be influencing load order in this environment.

Edited by Oswaldo Ferreira