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

Conflict resolution documentation #692

Open
philipbeber opened this issue Mar 14, 2022 · 1 comment
Open

Conflict resolution documentation #692

philipbeber opened this issue Mar 14, 2022 · 1 comment

Comments

@philipbeber
Copy link

philipbeber commented Mar 14, 2022

Describe the bug
The paragraph in the introduction describing conflict resolution stops mid-sentence: By default, only one lock for a given hash can be acquired. What happens when a lock can't be acquired is governed by a chosen [Conflict Strategy](https://github.com/mhenrixon/sidekiq-unique-jobs#conflict-strategy) strategy. Unless a conflict strategy is chosen

Expected behavior
It would be nice to know:

  • What happens when a conflict strategy is not chosen, i.e. what is the default behavior?
  • How does one simply ignore queuing a job if the lock is already taken (rather than sending it to the morgue)?
  • This text: By default, only one lock for a given hash can be acquired implies there's a way to have more than one lock for each hash. Is this a reference to the lock_args feature or something else?

Additional context
Great gem! Thanks for providing this. It is very useful.

@exterm
Copy link

exterm commented Apr 5, 2023

This would indeed be very helpful. I've spent some time reading through the code and it looks like the default confliect resolution strategy is [the null strategy(https://github.com/mhenrixon/sidekiq-unique-jobs/blob/main/lib/sidekiq_unique_jobs/on_conflict/null_strategy.rb). However, I'm not quite sure what behavior that entails.

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