batch_processor 0.2.5 → 0.2.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/lib/batch_processor/batch_job.rb +7 -2
- data/lib/batch_processor/version.rb +1 -1
- metadata +2 -2
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: e67aa3da97a88da1106578b16d93065d9cbcb8c1ad7045e4d1ca685a201bbb02
|
|
4
|
+
data.tar.gz: 52017c9ea65ebcec0092d3fd6740aa3aa13df2d89561470a58f28088fa182177
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 725655af2c8944fcbcf837a2cf80e01992310c5c37352bd10da0ef6efdc60192ddc1224437fd6e3008be48383673d101a6d43680235c4b41d4aa2ed2d7d02441
|
|
7
|
+
data.tar.gz: ce203c992d02fa528a5bab0971a5e38d29390de28312aba53ba0173681f5dbe5e3f5c45da95bbbe351e5c0ba34144cd5c7cab077fff8ab60fec9ab4417a67110
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
# A batch can only be processed by a batchable job.
|
|
4
4
|
module BatchProcessor
|
|
5
5
|
class BatchJob < ActiveJob::Base
|
|
6
|
-
attr_accessor :batch_id, :tracked_batch_running
|
|
6
|
+
attr_accessor :batch_id, :tracked_batch_running, :tracked_batch_failure
|
|
7
7
|
|
|
8
8
|
include Technologic
|
|
9
9
|
|
|
@@ -27,10 +27,15 @@ module BatchProcessor
|
|
|
27
27
|
|
|
28
28
|
after_perform(if: :batch_job?) { batch.job_success }
|
|
29
29
|
|
|
30
|
+
# Some combination of Sidekiq + ActiveJob + Postgres + Deadlocks = this getting called twice for the same instance.
|
|
31
|
+
# It is unclear WHY that situation happens, but during the second execution, the instance no longer has it's job_id
|
|
32
|
+
# but somehow still has a batch ID. It seems regardless, an internal semaphore seems to prevent miscounting in that
|
|
33
|
+
# situation. I'd love to know what the root cause is behind it, but async debugging is time consuming and hard. :(
|
|
30
34
|
def rescue_with_handler(exception)
|
|
31
35
|
batch.job_canceled and return exception if exception.is_a?(BatchAbortedError)
|
|
32
36
|
|
|
33
|
-
batch_job_failure(exception) if batch_job?
|
|
37
|
+
batch_job_failure(exception) if batch_job? && !tracked_batch_failure
|
|
38
|
+
self.tracked_batch_failure = true
|
|
34
39
|
|
|
35
40
|
super
|
|
36
41
|
end
|
metadata
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: batch_processor
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 0.2.
|
|
4
|
+
version: 0.2.6
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- Eric Garside
|
|
8
8
|
autorequire:
|
|
9
9
|
bindir: bin
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date: 2019-06-
|
|
11
|
+
date: 2019-06-27 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: activejob
|