README.md in sidekiq-unique-jobs-2.7.0 vs README.md in sidekiq-unique-jobs-2.7.1

@@ -22,23 +22,31 @@
 
 ```ruby
 sidekiq_options unique: true
 ```
 
+For jobs scheduled in the future it is possible to set for how long the job
+should be unique. The job will be unique for the number of seconds configured
+or until the job has been completed.
+
+*If you want the unique job to stick around even after it has been successfully
+processed then just set the unique_unlock_order to anything except `:before_yield` or `:after_yield` (`unique_unlock_order = :never`)
+
 You can also control the expiration length of the uniqueness check. If you want to enforce uniqueness over a longer period than the default of 30 minutes then you can pass the number of seconds you want to use to the sidekiq options:
 
 ```ruby
 sidekiq_options unique: true, unique_job_expiration: 120 * 60 # 2 hours
 ```
 
 Requiring the gem in your gemfile should be sufficient to enable unique jobs.
 
 ### Finer Control over Uniqueness
 
-Sometimes it is desired to have a finer control over which arguments are used in determining uniqueness of the job, and others may be _transient_. For this use-case, you need to
-set `SidekiqUniqueJobs::Config.unique_args_enabled` to true in an initializer, and then defined either `unique_args` method, or a ruby proc.
+Sometimes it is desired to have a finer control over which arguments are used in determining uniqueness of the job, and others may be _transient_. For this use-case, you need to set `SidekiqUniqueJobs::Config.unique_args_enabled` to true in an initializer, and then defined either `unique_args` method, or a ruby proc.
 
+The unique_args method need to return an array of values to use for uniqueness check.
+
 ```ruby
 SidekiqUniqueJobs::Config.unique_args_enabled = true
 ```
 
 The method or the proc can return a modified version of args without the transient arguments included, as shown below:
@@ -65,13 +73,10 @@
   ...
 
 end
 ```
 
-Note that objects passed into workers are converted to JSON *after* running through client middleware. In server
-middleware, the JSON is passed directly to the worker `#perform` method. So, you may run into issues where the
-arguments are different when enqueuing than they are when performing. Your `unique_args` method may need to
-account for this.
+Note that objects passed into workers are converted to JSON *after* running through client middleware. In server middleware, the JSON is passed directly to the worker `#perform` method. So, you may run into issues where the arguments are different when enqueuing than they are when performing. Your `unique_args` method may need to account for this.
 
 ### Unlock Ordering
 
 By default the server middleware will release the worker lock after yielding to the next middleware or worker. Alternatively, this can be changed by passing the `unique_unlock_order` option: