job-iteration 0.9.2 → 0.9.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 86ee54cb82b9d6c5e1b97b9bf2e01eed332ce87c
-  data.tar.gz: f05e54ca8459b37f472bfcd4f9cf47d9a005dc8b
+  metadata.gz: ad408d4be3681757ec2dbe9c530938610f3802fd
+  data.tar.gz: 9166829abfa92b0f552971a45ec7be86073664fe
 SHA512:
-  metadata.gz: aabb890775e006f0097bb886fddd6c9bdbeb442616e5fbb0c12d96ad8fe453ca1119ac1018cab36b9756188a0ccd28944a3e836032b1099a899f54b078c7ba64
-  data.tar.gz: 5133e2eff873e88d009aa255d3eb01bde85b589e24e9f1f660dbe60f15022c24585dded574b3a397ff8fb503dc97fda55b13f1ad24be5fadd1917a94c474c564
+  metadata.gz: 1c2bf184cc6f7a643d0bd50de0d83b9eeb3f36998b97f05628a892bda4ad15234d45c8f369a5d9969239924821f98b19f55e2289f55dcf442d07a76ef84e3d5f
+  data.tar.gz: 96f245daa9313d4adbde345cbc7bd298cf7ca9946bb481d5a98e8de0390293c584e0e6b4c2d8e5f1e126572b32780b60b43c938ae04c18e42cb0f19219fe0835

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    job-iteration (0.9.2)
+    job-iteration (0.9.3)
       activejob (~> 5.2)
 
 GEM

data/README.md

@@ -20,7 +20,7 @@ end
 
 The job would run fairly quickly when you only have a hundred `User` records. But as the number of records grows, it will take longer for a job to iterate over all Users. Eventually, there will be millions of records to iterate and the job will end up taking hours or even days.
 
-With frequent deploys and worker restarts, it would mean that a job will be either lost of started from the beginning. Some records (especially those in the beginning of the relation) will be processed more than once.
+With frequent deploys and worker restarts, it would mean that a job will be either lost or restarted from the beginning. Some records (especially those in the beginning of the relation) will be processed more than once.
 
 Cloud environments are also unpredictable, and there's no way to guarantee that a single job will have reserved hardware to run for hours and days. What if AWS diagnosed the instance as unhealthy and will restart it in 5 minutes? What if a Kubernetes pod is getting [evicted](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/)? Again, all job progress will be lost. At Shopify, we also use it to interrupt workloads safely when moving tenants between shards and move shards between regions.
 

data/lib/job-iteration/test_helper.rb

@@ -44,9 +44,9 @@ module JobIteration
 
     private
 
-    def stub_shutdown_adapter_to_return(_value)
+    def stub_shutdown_adapter_to_return(value)
       adapter = mock
-      adapter.stubs(:call).returns(false)
+      adapter.stubs(:call).returns(value)
       JobIteration.stubs(:interruption_adapter).returns(adapter)
     end
   end

data/lib/job-iteration/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module JobIteration
-  VERSION = "0.9.2"
+  VERSION = "0.9.3"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: job-iteration
 version: !ruby/object:Gem::Version
-  version: 0.9.2
+  version: 0.9.3
 platform: ruby
 authors:
 - Shopify
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2018-08-23 00:00:00.000000000 Z
+date: 2018-09-09 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activejob