Surviving rolling deploys when Sidekiq meets a class it doesn't know yet — dmitrytsepelev.dev

The culprit is the rolling deploy. When you roll out a new version, old and new processes run side by side for a while—that’s the whole point, zero downtime. During that window you have two kinds of processes in play: something that enqueues jobs: a freshly started pod, a scheduler (sidekiq-cron, sidekiq-scheduler, a clock process), or a web process already running the new code; something that executes jobs: a Sidekiq worker that might still be running the old code, because it hasn’t been restarted yet. The new code enqueues SendShinyNewThingJob. An old worker picks it up, tries to materialize the class from the queue payload, and—since that constant simply doesn’t exist in its process—blows up with a NameError. ActiveJob is no different: its Sidekiq wrapper calls job_class.constantize while deserializing the payload, so you get the very same error, just raised from inside the wrapper:.