sidekiq-unique-jobs icon indicating copy to clipboard operation
sidekiq-unique-jobs copied to clipboard

Different digests in v7 vs v6

Open AlexRiedler opened this issue 2 years ago • 6 comments

Describe the bug I am doing an upgrade from v6 to v7, and noticing verifying the integrity of the upgrade before applying it to production.

On v6.0.24 after performing a TestWorker.perform_async('foobar') i get the follow keys in redis:

"uniquejobs:24a90f1c44723cdd4120c4be34a6bdc0:EXISTS"
"uniquejobs:24a90f1c44723cdd4120c4be34a6bdc0:GRABBED"

However, on v7.1.8 I get:

"uniquejobs:50699ab033b41180f9adc8368180d8a4"
"uniquejobs:50699ab033b41180f9adc8368180d8a4:LOCKED"

I know we upgrade EXISTS to no suffix, and GRABBED to LOCKED between v6 and v7; so that seems right, but the digests should be the same correct?

Expected behavior

I expected the digests between v6 and v7 to the be same, but it seems like they are not...

Current behavior

Digests differ

Worker class

class TestWorker
  include Sidekiq::Worker
  sidekiq_options lock: :until_executing

  def perform(id)
  end
end

Additional context

Welcome to debug more, but just want to make sure I didn't overlook something in the v6 to v7 upgrade!

AlexRiedler avatar Oct 21 '21 09:10 AlexRiedler

That's weird, to my knowledge the digest should be the same!

mhenrixon avatar Oct 25 '21 16:10 mhenrixon

@mhenrixon looked into this more, thanks for getting back to me!

We renamed "unique_args" to "lock_args" in the digestable_hash:

V6:

{"class"=>"TestWorker", "queue"=>"default", "unique_args"=>["foo"]}

V7:

{"class"=>"TestWorker", "queue"=>"default", "lock_args"=>["foo"]}

As a result the digests are all different between versions. I guess for existing or upgraded jobs this doesn't matter because the digestable part will be the same.

However, you could create new jobs that wouldn't be unique with currently executing jobs during the migration. I have a way to work around this for the service I am upgrading; but others might not... I wonder what to do 😅

AlexRiedler avatar Oct 25 '21 20:10 AlexRiedler

Thanks for the report and the explanation. I'll see about updating the upgrading section or perhaps take this into consideration somehow.

mhenrixon avatar Nov 15 '21 14:11 mhenrixon

@mhenrixon @AlexRiedler just following up on this as we are looking to run an upgrade from v6 to v7 as well. Has this been confirmed that the digests are different? Any recommendations on how to mitigate having duplicate jobs running after the deployment to the new gem version since the digests are different?

lucasklaassen avatar Jan 06 '22 18:01 lucasklaassen

any update here ? :)

kirsha2 avatar Sep 29 '22 20:09 kirsha2

so our app will buggy if we do upgrade to v7?

saiqulhaq-hh avatar Nov 21 '22 02:11 saiqulhaq-hh