README.md in sidekiq-unique-jobs-8.0.2 vs README.md in sidekiq-unique-jobs-8.0.3
- old
+ new
@@ -43,15 +43,15 @@
- [lock_failed](#lock_failed)
- [locked](#locked)
- [reschedule_failed](#reschedule_failed)
- [rescheduled](#rescheduled)
- [timeout](#timeout)
- - [unlock_failed](#unlock_failed)
- - [unlocked](#unlocked)
- - [unknown_sidekiq_worker](#unknown_sidekiq_worker)
- - [Show Locks](#show-locks)
- - [Show Lock](#show-lock)
+ - [unlock_failed](#unlock_failed)
+ - [unlocked](#unlocked)
+ - [unknown_sidekiq_worker](#unknown_sidekiq_worker)
+ - [Show Locks](#show-locks)
+ - [Show Lock](#show-lock)
- [Testing](#testing)
- [Validating Worker Configuration](#validating-worker-configuration)
- [Uniqueness](#uniqueness)
- [Configuration](#configuration)
- [Other Sidekiq gems](#other-sidekiq-gems)
@@ -543,26 +543,26 @@
#### timeout
This is also mostly useful for reporting/metrics purposes. What this reflection does is signal that the job was configured to wait (`lock_timeout` was configured), but we couldn't retrieve a lock even though we waited for some time.
-### unlock_failed
+#### unlock_failed
-This is not got, this is worth
+This means that the server middleware could not unlock your job and the lock is kept (potentially preventing subsequent jobs from being pushed or processed).
-### unlocked
+#### unlocked
Also mostly useful for reporting purposes. The job was successfully unlocked.
-### unknown_sidekiq_worker
+#### unknown_sidekiq_worker
The reason this happens is that the server couldn't find a valid sidekiq worker class. Most likely, that worker isn't intended to be processed by this sidekiq server instance.
-#### Show Locks
+### Show Locks
-#### Show Lock
+### Show Lock
## Testing