job-iteration 0.9.0 → 0.9.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: e042aee693c7b308e483fd6276a9966894dacf75
-  data.tar.gz: bd8fe09135913110159faaaa7498e0786877650a
+  metadata.gz: 744271afc9d1de8f525a2228d4969e182118affa
+  data.tar.gz: fa9d46fc8fbafba32134de730525d2ada4efc784
 SHA512:
-  metadata.gz: ef8ca88e85af8844864511165062f1dc75d23b34d8161849ae7db55ddb9f8e70bf53c58cb96465800cb82c717eb34b945c6a55a6f8d8e88861c661a302723f69
-  data.tar.gz: 2854303407e9d67bbc727970b0ee979f74a63917039ffa356efba86ed6b8f3b4eb29a42d56735e9516404d203cd890af8850f84e979f83ff1a581aafb76819d8
+  metadata.gz: 83e1ca25924c4d273b1ed5a19eed81565479f90aaebdadd50c12c5c19643437bfc330798328dc10abc1a10f7fc63b755cbcbd2c5d34e162a4ff723979757edb9
+  data.tar.gz: 34b83d31905e210800ca4237bb786c1492842e80e3aeadad137dae40e96b9eb92d675521c8941c4c43ae419e2e0967d2b1389220164c803954eb800abc449ef8

data/.yardopts

@@ -0,0 +1,3 @@
+--no-private
+--embed-mixins
+--markup markdown

data/Gemfile

@@ -22,3 +22,4 @@ gem 'pry'
 gem 'mocha'
 
 gem 'rubocop'
+gem 'yard'

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    job-iteration (0.9.0)
+    job-iteration (0.9.1)
       activejob (~> 5.2)
 
 GEM
@@ -88,6 +88,7 @@ GEM
     unicode-display_width (1.4.0)
     vegas (0.1.11)
       rack (>= 1.0.0)
+    yard (0.9.15)
 
 PLATFORMS
   ruby
@@ -108,6 +109,7 @@ DEPENDENCIES
   resque
   rubocop
   sidekiq
+  yard
 
 BUNDLED WITH
-   1.16.1
+   1.16.3

data/README.md

@@ -1,5 +1,7 @@
 # Job Iteration API
 
+[![Build Status](https://travis-ci.com/Shopify/job-iteration.svg?branch=master)](https://travis-ci.com/Shopify/job-iteration)
+
 Meet Iteration, an extension for [ActiveJob](https://github.com/rails/rails/tree/master/activejob) that makes your jobs interruptible and resumable, saving all progress that the job has made (aka checkpoint for jobs).
 
 ## Background
@@ -16,15 +18,15 @@ class SimpleJob < ActiveJob::Base
 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 and days.
+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.
 
-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 Kubernetes pod is getting [evicted](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/)? Again, all job progress will be lost.
+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.
 
-Software that is designed for high availability [must be friendly](https://12factor.net/disposability) to interruptions that come from the infrastructure. That's exactly what Iteration brings to ActiveJob. It's been developed at Shopify to safely process long-running jobs, in Cloud, and has been working in production since May 2017.
+Software that is designed for high availability [must be resilient](https://12factor.net/disposability) to interruptions that come from the infrastructure. That's exactly what Iteration brings to ActiveJob. It's been developed at Shopify to safely process long-running jobs, in Cloud, and has been working in production since May 2017.
 
-We recommend you to watch a [conference talk](https://www.youtube.com/watch?v=XvnWjsmAl60) about the ideas and history behind Iteration API.
+We recommend that you watch one of our [conference talks](https://www.youtube.com/watch?v=XvnWjsmAl60) about the ideas and history behind Iteration API.
 
 ## Getting started
 
@@ -103,10 +105,15 @@ class CsvJob < ActiveJob::Iteration
 end
 ```
 
+Iteration hooks into Sidekiq and Resque out of the box to support graceful interruption. No extra configuration is required.
+
 ## Guides
 
-* [Iteration: how it works](guides/iteration-how-it-works.md).
-* [Best practices](guides/best-practices.md).
+* [Iteration: how it works](guides/iteration-how-it-works.md)
+* [Best practices](guides/best-practices.md)
+* [Writing custom enumerator](guides/custom-enumerator.md)
+
+For more detailed documentation, see [rubydoc](https://www.rubydoc.info/github/Shopify/job-iteration).
 
 ## Requirements
 
@@ -132,11 +139,11 @@ There a few configuration assumptions that are required for Iteration to work wi
 
 **What happens with retries?** An interruption of a job does not count as a retry. The iteration of job that caused the job to fail will be retried and progress will continue from there on.
 
-**What happens if my iteration takes a long time?** We recommend that a single `each_iteration` should take no longer than 30 seconds. In the future, this may raise.
+**What happens if my iteration takes a long time?** We recommend that a single `each_iteration` should take no longer than 30 seconds. In the future, this may raise an exception.
 
 **Why is it important that `each_iteration` takes less than 30 seconds?** When the job worker is scheduled for restart or shutdown, it gets a notice to finish remaining unit of work. To guarantee that no progress is lost we need to make sure that `each_iteration` completes within a reasonable amount of time.
 
-**What do I do if each iteration takes a long time, because it's doing nested operations?** If your `each_iteration` is complex, we recommend enqueuing another job. We may expose primitives in the future to do this more effectively, but this is not terribly common today. We recommend to read https://goo.gl/UobaaU to learn more about nested operations.
+**What do I do if each iteration takes a long time, because it's doing nested operations?** If your `each_iteration` is complex, we recommend enqueuing another job, which will run your nested business logic. We may expose primitives in the future to do this more effectively, but this is not terribly common today. We recommend to read https://goo.gl/UobaaU to learn more about nested operations.
 
 **Why do I use have to use this ugly helper in `build_enumerator`? Why can't you automatically infer it?** This is how the first version of the API worked. We checked the type of object returned by `build_enumerable`, and whether it was ActiveRecord Relation or an Array, we used the matching adapter. This caused opaque type branching in Iteration internals and it didn’t allow developers to craft their own Enumerators and control the cursor value. We made a decision to _always_ return Enumerator instance from `build_enumerator`. Now we provide explicit helpers to convert ActiveRecord Relation or an Array to Enumerator, and for more complex iteration flows developers can build their own `Enumerator` objects.
 

data/guides/custom-enumerator.md

@@ -0,0 +1,74 @@
+Iteration leverages the [Enumerator](http://ruby-doc.org/core-2.5.1/Enumerator.html) pattern from the Ruby standard library, which allows us to use almost any resource as a collection to iterate.
+
+Consider a custom Enumerator that takes items from a Redis list. Because a Redis List is essentially a queue, we can ignore the cursor:
+
+```ruby
+class ListJob < ActiveJob::Base
+  include JobIteration::Iteration
+
+  def build_enumerator(*)
+    @redis = Redis.new
+    Enumerator.new |yielder|
+      yielder.yield @redis.lpop(key), nil
+    end
+  end
+
+  def each_iteration(item_from_redis)
+    # ...
+  end
+end
+```
+
+But what about iterating based on a cursor? Consider this Enumerator that wraps third party API (Stripe) for paginated iteration:
+
+```ruby
+class StripeListEnumerator
+  # @param resource [Stripe::APIResource] The type of Stripe object to request
+  # @param params [Hash] Query parameters for the request
+  # @param options [Hash] Request options, such as API key or version
+  # @param cursor [String]
+  def initialize(resource, params: {}, options: {}, cursor:)
+    pagination_params = {}
+    pagination_params[:starting_after] = cursor unless cursor.nil?
+
+    @list = resource.public_send(:list, params.merge(pagination_params), options)
+      .auto_paging_each.lazy
+  end
+
+  def to_enumerator
+    to_enum(:each).lazy
+  end
+
+  private
+
+  # We yield our enumerator with the object id as the index so it is persisted
+  # as the cursor on the job. This allows us to properly set the
+  # `starting_after` parameter for the API request when resuming.
+  def each
+    @list.each do |item, _index|
+      yield item, item.id
+    end
+  end
+end
+```
+
+```ruby
+class StripeJob < ActiveJob::Base
+  include JobIteration::Iteration
+
+  def build_enumerator(params, cursor:)
+    StripeListEnumerator.new(
+      Stripe::Refund,
+      params: { charge: "ch_123" },
+      options: { api_key: "sk_test_123", stripe_version: "2018-01-18" },
+      cursor: cursor
+    ).to_enumerator
+  end
+
+  def each_iteration(stripe_refund, _params)
+    # ...
+  end
+end
+```
+
+We recommend that you read the implementation of the other enumerators that come with the library (`CsvEnumerator`, `ActiveRecordEnumerator`) to gain a better understanding of building Enumerator objects.

data/guides/iteration-how-it-works.md

@@ -1,8 +1,8 @@
 # Iteration: how it works
 
-The main idea behind Iteration is to provide an API to describe jobs in interruptible manner, on the contrast with one massive `def perform` that is impossible to interrupt safely.
+The main idea behind Iteration is to provide an API to describe jobs in an interruptible manner, in contrast with implementing one massive `#perform` method that is impossible to interrupt safely.
 
-Exposing the enumerator and the action to apply allows us to keep the cursor and interrupt between iterations. Let's see how it looks like on example of an ActiveRecord relation (and Enumerator).
+Exposing the enumerator and the action to apply allows us to keep a cursor and interrupt between iterations. Let's see what this looks like with an  ActiveRecord relation (and Enumerator).
 
 1. `build_enumerator` is called, which constructs `ActiveRecordEnumerator` from an ActiveRecord relation (`Product.all`)
 2. The first batch of records is loaded:
@@ -11,9 +11,9 @@ Exposing the enumerator and the action to apply allows us to keep the cursor and
 SELECT  `products`.* FROM `products` ORDER BY products.id LIMIT 100
 ```
 
-3. Job iterates over two records of the relation and then receives `SIGTERM` (graceful termination signal) caused by a deploy
-4. Signal handler sets a flag that makes `job_should_exit?` to return `true`
-5. After the last iteration is completed, we will check `job_should_exit?` which now returns `true`
+3. The job iterates over two records of the relation and then receives `SIGTERM` (graceful termination signal) caused by a deploy.
+4. The signal handler sets a flag that makes `job_should_exit?` return `true`.
+5. After the last iteration is completed, we will check `job_should_exit?` which now returns `true`.
 6. The job stops iterating and pushes itself back to the queue, with the latest `cursor_position` value.
 7. Next time when the job is taken from the queue, we'll load records starting from the last primary key that was processed:
 
@@ -23,18 +23,18 @@ SELECT  `products`.* FROM `products` WHERE (products.id > 2) ORDER BY products.i
 
 ## Signals
 
-It's critical to know UNIX signals in order to understand how interruption works. There are two main signals that Sidekiq and Resque use: `SIGTERM` and `SIGKILL`. `SIGTERM` is the graceful termination signal which means that the process should exit _soon_, not immediately. For Iteration, it means that we have time to wait for the last iteration to finish and to push job back to the queue with the last cursor position.
+It's critical to know [UNIX signals](https://www.tutorialspoint.com/unix/unix-signals-traps.htm) in order to understand how interruption works. There are two main signals that Sidekiq and Resque use: `SIGTERM` and `SIGKILL`. `SIGTERM` is the graceful termination signal which means that the process should exit _soon_, not immediately. For Iteration, it means that we have time to wait for the last iteration to finish and to push job back to the queue with the last cursor position.
 `SIGTERM` is what allows Iteration to work. In contrast, `SIGKILL` means immediate exit. It doesn't let the worker terminate gracefully, instead it will drop the job and exit as soon as possible.
 
-Most of deploy strategies (Kubernetes, Heroku, Capistrano) send `SIGTERM` before the shut down, then wait for the a timeout (usually from 30 seconds to a minute) and send `SIGKILL` if the process haven't terminated yet.
+Most of the deploy strategies (Kubernetes, Heroku, Capistrano) send `SIGTERM` before shutting down a node, then wait for a timeout (usually from 30 seconds to a minute) to send `SIGKILL` if the process has not terminated yet.
 
 Further reading: [Sidekiq signals](https://github.com/mperham/sidekiq/wiki/Signals).
 
 ## Enumerators
 
-In the early versions of Iteration, `build_enumerator` used to return ActiveRecord relations directly, and we would infer the Enumerator based on the type of object. We used to support ActiveRecord relations, arrays and CSVs. This way it was hard to add support for anything else to enumerate, and it was easy for developers to make a mistake and return an array of ActiveRecord objects, and for us starting to threat that as an array instead of ActiveRecord relation.
+In the early versions of Iteration, `build_enumerator` used to return ActiveRecord relations directly, and we would infer the Enumerator based on the type of object. We used to support ActiveRecord relations, arrays and CSVs. This made it hard to add support for other types of enumerations, and it was easy for developers to make mistakes and return an array of ActiveRecord objects, and for us starting to treat that as an array instead of as an ActiveRecord relation.
 
-In the current version of Iteration, it supports _any_ Enumerator. We expose helpers to build enumerators conveniently (`enumerator_builder.active_record_on_records`), but it's up for a developer to implement a custom Enumerator. Consider this example:
+The current version of Iteration supports _any_ Enumerator. We expose helpers to build enumerators conveniently (`enumerator_builder.active_record_on_records`), but it's up for a developer to implement a custom Enumerator. Consider this example:
 
 ```ruby
 class MyJob < ActiveJob::Base

data/lib/job-iteration.rb

@@ -1,33 +1,43 @@
 # frozen_string_literal: true
 
-require "job-iteration/version"
-require "job-iteration/enumerator_builder"
-require "job-iteration/iteration"
+require_relative "./job-iteration/version"
+require_relative "./job-iteration/enumerator_builder"
+require_relative "./job-iteration/iteration"
 
 module JobIteration
+  IntegrationLoadError = Class.new(StandardError)
+
   INTEGRATIONS = [:resque, :sidekiq]
 
   extend self
 
   attr_accessor :max_job_runtime, :interruption_adapter
-
-  module AlwaysRunningInterruptionAdapter
-    extend self
-
-    def shutdown?
-      false
-    end
-  end
-  self.interruption_adapter = AlwaysRunningInterruptionAdapter
+  self.interruption_adapter = -> { false }
 
   def load_integrations
+    loaded = nil
     INTEGRATIONS.each do |integration|
       begin
-        require "job-iteration/integrations/#{integration}"
+        load_integration(integration)
+        if loaded
+          raise IntegrationLoadError,
+            "#{loaded} integration has already been loaded, but #{integration} is also available. " \
+            "Iteration will only work with one integration."
+        end
+        loaded = integration
       rescue LoadError
       end
     end
   end
+
+  def load_integration(integration)
+    unless INTEGRATIONS.include?(integration)
+      raise IntegrationLoadError,
+        "#{integration} integration is not supported. Available integrations: #{INTEGRATIONS.join(', ')}"
+    end
+
+    require_relative "./job-iteration/integrations/#{integration}"
+  end
 end
 
 JobIteration.load_integrations unless ENV['ITERATION_DISABLE_AUTOCONFIGURE']

data/lib/job-iteration/active_record_cursor.rb

@@ -1,7 +1,7 @@
 # frozen_string_literal: true
 
 module JobIteration
-  class ActiveRecordCursor
+  class ActiveRecordCursor # @private
     include Comparable
 
     attr_reader :position

data/lib/job-iteration/active_record_enumerator.rb

@@ -1,6 +1,8 @@
 # frozen_string_literal: true
 require_relative "./active_record_cursor"
 module JobIteration
+  # Builds Enumerator based on ActiveRecord Relation. Supports enumerating on rows and batches.
+  # @see EnumeratorBuilder
   class ActiveRecordEnumerator
     def initialize(relation, columns: nil, batch_size: 100, cursor: nil)
       @relation = relation

data/lib/job-iteration/csv_enumerator.rb

@@ -1,7 +1,24 @@
 # frozen_string_literal: true
 
 module JobIteration
+  # CsvEnumerator makes it possible to write an Iteration job
+  # that uses CSV file as a collection to Iterate.
+  # @example
+  #   def build_enumerator(cursor:)
+  #     csv = CSV.open('tmp/files', { converters: :integer, headers: true })
+  #     JobIteration::CsvEnumerator.new(csv).rows(cursor: cursor)
+  #   end
+  #
+  #   def each_iteration(row)
+  #     ...
+  #   end
   class CsvEnumerator
+    # Constructs CsvEnumerator instance based on a CSV file.
+    # @param [CSV] csv An instance of CSV object
+    # @return [JobIteration::CsvEnumerator]
+    # @example
+    #   csv = CSV.open('tmp/files', { converters: :integer, headers: true })
+    #   JobIteration::CsvEnumerator.new(csv).rows(cursor: cursor)
     def initialize(csv)
       unless csv.instance_of?(CSV)
         raise ArgumentError, "CsvEnumerator.new takes CSV object"
@@ -10,6 +27,8 @@ module JobIteration
       @csv = csv
     end
 
+    # Constructs a enumerator on CSV rows
+    # @return [Enumerator] Enumerator instance
     def rows(cursor:)
       @csv.lazy
         .each_with_index
@@ -17,6 +36,8 @@ module JobIteration
         .to_enum { count_rows_in_file }
     end
 
+    # Constructs a enumerator on batches of CSV rows
+    # @return [Enumerator] Enumerator instance
     def batches(batch_size:, cursor:)
       @csv.lazy
         .each_slice(batch_size)

data/lib/job-iteration/integrations/resque.rb

@@ -4,23 +4,15 @@ require 'resque'
 
 module JobIteration
   module Integrations
-    # The trick is required in order to call shutdown? on a Resque::Worker instance
-    module ResqueIterationExtension
-      def initialize(*)
+    module ResqueIterationExtension # @private
+      def initialize(*) # @private
         $resque_worker = self
         super
       end
     end
+    # The patch is required in order to call shutdown? on a Resque::Worker instance
     Resque::Worker.prepend(ResqueIterationExtension)
 
-    module ResqueInterruptionAdapter
-      extend self
-
-      def shutdown?
-        $resque_worker.try!(:shutdown?)
-      end
-    end
-
-    JobIteration.interruption_adapter = ResqueInterruptionAdapter
+    JobIteration.interruption_adapter = -> { $resque_worker.try!(:shutdown?) }
   end
 end

data/lib/job-iteration/integrations/sidekiq.rb

@@ -3,19 +3,13 @@
 require 'sidekiq'
 
 module JobIteration
-  module Integrations
-    module SidekiqInterruptionAdapter
-      extend self
-
-      def shutdown?
-        if defined?(Sidekiq::CLI) && Sidekiq::CLI.instance
-          Sidekiq::CLI.instance.launcher.stopping?
-        else
-          false
-        end
+  module Integrations # @private
+    JobIteration.interruption_adapter = -> do
+      if defined?(Sidekiq::CLI) && Sidekiq::CLI.instance
+        Sidekiq::CLI.instance.launcher.stopping?
+      else
+        false
       end
     end
-
-    JobIteration.interruption_adapter = SidekiqInterruptionAdapter
   end
 end

data/lib/job-iteration/iteration.rb

@@ -53,7 +53,7 @@ module JobIteration
       self.total_time = 0.0
     end
 
-    def serialize
+    def serialize # @private
       super.merge(
         'cursor_position' => cursor_position,
         'times_interrupted' => times_interrupted,
@@ -61,14 +61,14 @@ module JobIteration
       )
     end
 
-    def deserialize(job_data)
+    def deserialize(job_data) # @private
       super
       self.cursor_position = job_data['cursor_position']
       self.times_interrupted = job_data['times_interrupted'] || 0
       self.total_time = job_data['total_time'] || 0
     end
 
-    def perform(*params)
+    def perform(*params) # @private
       interruptible_perform(*params)
     end
 
@@ -198,7 +198,7 @@ module JobIteration
         return true
       end
 
-      JobIteration.interruption_adapter.shutdown?
+      JobIteration.interruption_adapter.call || (defined?(super) && super)
     end
   end
 end

data/lib/job-iteration/test_helper.rb

@@ -1,40 +1,52 @@
 # frozen_string_literal: true
 
 module JobIteration
+  # Include JobIteration::TestHelper to mock interruption when testing your jobs.
   module TestHelper
-    class StoppingSupervisor
+    class StoppingSupervisor # @private
       def initialize(stop_after_count)
         @stop_after_count = stop_after_count
         @calls = 0
       end
 
-      def shutdown?
+      def call
         @calls += 1
         (@calls % @stop_after_count) == 0
       end
     end
 
-    private
-
+    # Stubs interruption adapter to interrupt the job after every N iterations.
+    # @param [Integer] n_times Number of times before the job is interrupted
+    # @example
+    #   test "this stuff interrupts" do
+    #     iterate_exact_times(3.times)
+    #     MyJob.perform_now
+    #   end
     def iterate_exact_times(n_times)
       JobIteration.stubs(:interruption_adapter).returns(StoppingSupervisor.new(n_times.size))
     end
 
+    # Stubs interruption adapter to interrupt the job after every sing iteration.
+    # @see #iterate_exact_times
     def iterate_once
       iterate_exact_times(1.times)
     end
 
+    # Removes previous stubs and tells the job to iterate until the end.
     def continue_iterating
       stub_shutdown_adapter_to_return(false)
     end
 
+    # Stubs the worker as already interrupted.
     def mark_job_worker_as_interrupted
       stub_shutdown_adapter_to_return(true)
     end
 
+    private
+
     def stub_shutdown_adapter_to_return(_value)
       adapter = mock
-      adapter.stubs(:shutdown?).returns(false)
+      adapter.stubs(:call).returns(false)
       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.0"
+  VERSION = "0.9.1"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: job-iteration
 version: !ruby/object:Gem::Version
-  version: 0.9.0
+  version: 0.9.1
 platform: ruby
 authors:
 - Shopify
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2018-07-12 00:00:00.000000000 Z
+date: 2018-08-14 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activejob
@@ -76,6 +76,7 @@ files:
 - ".gitignore"
 - ".rubocop.yml"
 - ".travis.yml"
+- ".yardopts"
 - CODE_OF_CONDUCT.md
 - Gemfile
 - Gemfile.lock
@@ -83,6 +84,7 @@ files:
 - README.md
 - Rakefile
 - guides/best-practices.md
+- guides/custom-enumerator.md
 - guides/iteration-how-it-works.md
 - job-iteration.gemspec
 - lib/job-iteration.rb