You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+35-1
Original file line number
Diff line number
Diff line change
@@ -32,7 +32,41 @@ Or install it yourself as:
32
32
33
33
## Usage
34
34
35
-
Sidekiq Batch is drop-in replacement for the API from Sidekiq PRO. See https://github.com/mperham/sidekiq/wiki/Batches for usage.
35
+
Sidekiq Batch is MOSTLY a drop-in replacement for the API from Sidekiq PRO. See https://github.com/mperham/sidekiq/wiki/Batches for usage.
36
+
37
+
## Caveats/Gotchas
38
+
39
+
Consider the following workflow:
40
+
41
+
* Batch Z created
42
+
* Worker A queued in batch Z
43
+
* Worker A starts Worker B in batch Z
44
+
* Worker B completes *before* worker A does
45
+
* Worker A completes
46
+
47
+
In the standard configuration, the `on(:success)` and `on(:complete)` callbacks will be triggered when Worker B completes.
48
+
This configuration is the default, simply for legacy reasons. This gem adds the following option to the sidekiq.yml options:
49
+
50
+
```yaml
51
+
:batch_push_interval: 0
52
+
```
53
+
54
+
When this value is *absent* (aka legacy), Worker A will only push the increment of batch jobs (aka Worker B) *when it completes*
55
+
56
+
When this value is set to `0`, Worker A will increment the count as soon as `WorkerB.perform_async` is called
57
+
58
+
When this value is a positive number, Worker A will wait a maximum of value-seconds before pushing the increment to redis, or until it's done, whichever comes first.
59
+
60
+
This comes into play if Worker A is queueing thousands of WorkerB jobs, or has some other reason for WorkerB to complete beforehand.
61
+
62
+
If you are queueing many WorkerB jobs, it is recommended to set this value to something like `3` to avoid thousands of calls to redis, and call WorkerB like so:
63
+
```ruby
64
+
WorkerB.perform_in(4.seconds, some, args)
65
+
```
66
+
this will ensure that the batch callback does not get triggered until WorkerA *and* the last WorkerB job complete.
67
+
68
+
If WorkerA is just slow for whatever reason, setting to `0` will update the batch status immediately so that the callbacks don't fire.
0 commit comments