There was an issue with makandra_sidekiq < 0.2 concerning the stopping of Sidekiq.

Do you need DevOps-experts?

Your development team has a full backlog? No time for infrastructure architecture? Our DevOps team is ready to support you!

• We build reliable cloud solutions with Infrastructure as code
• We are experts in security, Linux and databases
• We support your dev team to perform

Read more Show archive.org snapshot

Sidekiq < 6 has two finishing timeouts Show archive.org snapshot : one for finishing things itself (A), and one for sidekiqctl before killing a running Sidekiq instance (B). While USAGE banner of sidekiqctl advises to have B always greater than A, makandra_sidekiq < 0.2 runs sidekiqctl without passing a timeout. If the Sidekiq instance is configured with a timeout higher than the default 10s timeout of sidekiqctl, sidekiqctl will kill the Sidekiq instance before it was able to requeue its running jobs. As a result, running jobs are canceled and lost! Note that this affects only jobs that run longer than 10 seconds.

makandra_sidekiq 0.2.0 fixes this by reading the configured Sidekiq timeout from config/sidekiq.yml and respecting it for stopping. This way, Sidekiq has time to requeue its current jobs and quit by itself before it would be killed by sidekiqctl.

We suggest that all users of makandra_sidekiq update soon to make sure they do not loose Sidekiq jobs.

Note that "quieting" the Sidekiq instance Show archive.org snapshot some time before "stopping" will keep Sidekiq from starting new jobs while processing its current ones. This way, Sidekiq is granted additional time to finish off its current tasks. This is especially useful and simple during deployments Show archive.org snapshot .