Skip to content
New issue

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

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

Already on GitHub? Sign in 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.

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

No branches or pull requests

2 participants