-
-
Notifications
You must be signed in to change notification settings - Fork 279
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
lock_args does not work when you define the lock_args argument and default lock_args function at the same time. #548
Comments
You must only define the I'll see if I can create a failing test for this. |
That makes sense. However, I took the failing example copy pasted exactly from the documentation. So it is a little confusing on what the correct definition would be. |
@fekadeabdejene I can't replicate this in my tests. Which sidekiq version are you on? |
6.1.2 |
Great find! This will require some additional changes: Instead of I won't release it just yet, I need to write some better coverage for this tomorrow. I want to also backport this to v6. |
Fixed and released as https://github.com/mhenrixon/sidekiq-unique-jobs/releases/tag/v7.0.0.beta27 |
Wow quick work - thank you! |
Version:
7.0.0.beta25
Describe the bug
The self.lock_args class method is never called when the lock_args parameter is defined in the sidekiq_options method.
Expected behavior
The self.lock_args class method should be called when it is defined in the sidekiq_options lock_args: :lock_args. Or the documentation should be updated to reflect this behaviour. Conversely, unique_args works when it is defined in the class and sidekiq_options unique_args: :unique_args. So there should be some consistency there.
Current behavior
Currently, the self.lock_args is never called when it is defined in the lock_args parameter.
Worker class
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: