Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Different unique arguments depending on lock type #203

Closed
stanley90 opened this issue Dec 6, 2016 · 6 comments
Closed

Different unique arguments depending on lock type #203

stanley90 opened this issue Dec 6, 2016 · 6 comments

Comments

@stanley90
Copy link

Hi
I want to use the until_and_while_executing option but with different unique arguments. Let's say my worker has two arguments: id, date
I want the jobs to be unique by both arguments in the queue, but only by the id during execution.
Is this possible?
Thanks

@stanley90
Copy link
Author

I think this could be achieved by sending the lock type to unique_args so the method can decide, but I don't want to hack too much right now, so I think I'll check the caller to determine whether it's in Sidekiq (runtime) or not (queuing).

@mhenrixon
Copy link
Owner

What solution did you end up with?

@stanley90
Copy link
Author

I did this:

sidekiq_options unique: :until_and_while_executing, unique_args: :unique_args

def self.unique_args(args)
  if Sidekiq::ProcessSet.new.size > 1
    # sidekiq runtime; uniqueness for the object (first arg)
    args.first
  else
    # queuing from the app; uniqueness for all params
    args
  end
end

@mhenrixon
Copy link
Owner

Thanks for the quick response @stanley90. Interesting solution, idn't know about ProcessSet! Does it work with the currently performing job somehow or is it more generic?

@stanley90
Copy link
Author

I don't remember exactly, it's been a while. I was looking for a way to distinguish in which context is the current process running, and found this (there might be other ways too); I think it was 0 in the app context (queuing) and a positive value in the actual background processing. Now looking at it, maybe the condition should actually be > 0, not > 1 :-)

@mhenrixon
Copy link
Owner

I'm adding some information in the README for this and closing the issue.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants