acidic_job 0.7.7 → 1.0.0.pre3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1ded2615559a3d31060c34d9b7e17717cb6f0afa60081f98df1cf451d8aa61c9
-  data.tar.gz: ce66fe904f29a0a5d47a834414de8b50f4de945cd41b0087e5d85265238c31b5
+  metadata.gz: b7c1aec259fa05e5cd62425643534a6944b44df91e1077dfb2eb98fa0717c3e1
+  data.tar.gz: 1e9759e91c7a10ea89f39626add3c60b5c3856d54a380958b9f4e6455c6cc937
 SHA512:
-  metadata.gz: 8dd451aeb1da7539193db26a4a42adc0b04b1ad48ecf71438cee14a78c8b352e287d43f838716eb4f4d8957210aba583b12c0d8e064dcbf6d4aa746310e4489f
-  data.tar.gz: aab8e61fc8292a6354e993ea98eaffe30350649c0cfce56ba974c732aa5c43f4c51b3f94a9aeec7cf0613ff36ebf1af6e761df85196426867ae1e1dd33679e0d
+  metadata.gz: 53d61ee2cee38e5e4a136eb37386c2bb912933ba35f839949ac411c486dd14091478d5d23ae3bb2d4ebd3f4c2d9f051e77a64ef1113f8fec2e533f7209662cdd
+  data.tar.gz: b8e4dcb13d2f4551d1cc37271003eff592bc03791c77edd3224d306d211c240b850ef258d184155511c29983af349ef9039b4b2dab99d298cc925a36217d7f11

data/.gitignore

@@ -9,3 +9,4 @@
 .DS_Store
 /test/database.sqlite
 slides.md
+/test/dummy

data/.rubocop.yml

@@ -15,3 +15,24 @@ Layout/LineLength:
 
 Style/Documentation:
   Enabled: false
+
+Metrics/ModuleLength:
+  Enabled: false
+  
+Metrics/AbcSize:
+  Enabled: false
+  
+Metrics/MethodLength:
+  Enabled: false
+  
+Metrics/BlockLength:
+  Enabled: false
+  
+Metrics/CyclomaticComplexity:
+  Enabled: false
+  
+Metrics/PerceivedComplexity:
+  Enabled: false
+
+Metrics/ClassLength:
+  Enabled: false

data/Gemfile

@@ -28,3 +28,9 @@ gem "simplecov"
 gem "pry"
 
 gem "sidekiq"
+
+gem "noticed"
+
+gem "combustion"
+
+gem "warning"

data/Gemfile.lock

@@ -1,13 +1,32 @@
 PATH
   remote: .
   specs:
-    acidic_job (0.7.7)
-      activerecord (>= 4.0.0)
+    acidic_job (1.0.0.pre3)
+      activerecord (>= 6.1.0)
       activesupport
 
 GEM
   remote: https://rubygems.org/
   specs:
+    actioncable (6.1.3.2)
+      actionpack (= 6.1.3.2)
+      activesupport (= 6.1.3.2)
+      nio4r (~> 2.0)
+      websocket-driver (>= 0.6.1)
+    actionmailbox (6.1.3.2)
+      actionpack (= 6.1.3.2)
+      activejob (= 6.1.3.2)
+      activerecord (= 6.1.3.2)
+      activestorage (= 6.1.3.2)
+      activesupport (= 6.1.3.2)
+      mail (>= 2.7.1)
+    actionmailer (6.1.3.2)
+      actionpack (= 6.1.3.2)
+      actionview (= 6.1.3.2)
+      activejob (= 6.1.3.2)
+      activesupport (= 6.1.3.2)
+      mail (~> 2.5, >= 2.5.4)
+      rails-dom-testing (~> 2.0)
     actionpack (6.1.3.2)
       actionview (= 6.1.3.2)
       activesupport (= 6.1.3.2)
@@ -15,6 +34,12 @@ GEM
       rack-test (>= 0.6.3)
       rails-dom-testing (~> 2.0)
       rails-html-sanitizer (~> 1.0, >= 1.2.0)
+    actiontext (6.1.3.2)
+      actionpack (= 6.1.3.2)
+      activerecord (= 6.1.3.2)
+      activestorage (= 6.1.3.2)
+      activesupport (= 6.1.3.2)
+      nokogiri (>= 1.8.5)
     actionview (6.1.3.2)
       activesupport (= 6.1.3.2)
       builder (~> 3.1)
@@ -29,15 +54,28 @@ GEM
     activerecord (6.1.3.2)
       activemodel (= 6.1.3.2)
       activesupport (= 6.1.3.2)
+    activestorage (6.1.3.2)
+      actionpack (= 6.1.3.2)
+      activejob (= 6.1.3.2)
+      activerecord (= 6.1.3.2)
+      activesupport (= 6.1.3.2)
+      marcel (~> 1.0.0)
+      mini_mime (~> 1.0.2)
     activesupport (6.1.3.2)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 1.6, < 2)
       minitest (>= 5.1)
       tzinfo (~> 2.0)
       zeitwerk (~> 2.3)
+    addressable (2.8.0)
+      public_suffix (>= 2.0.2, < 5.0)
     ast (2.4.2)
     builder (3.2.4)
     coderay (1.1.3)
+    combustion (1.3.5)
+      activesupport (>= 3.0.0)
+      railties (>= 3.0.0)
+      thor (>= 0.14.6)
     concurrent-ruby (1.1.9)
     connection_pool (2.2.5)
     crass (1.0.6)
@@ -48,30 +86,71 @@ GEM
       database_cleaner-core (~> 2.0.0)
     database_cleaner-core (2.0.1)
     docile (1.4.0)
+    domain_name (0.5.20190701)
+      unf (>= 0.0.5, < 1.0.0)
     erubi (1.10.0)
+    ffi (1.15.5)
+    ffi-compiler (1.0.1)
+      ffi (>= 1.0.0)
+      rake
     globalid (0.4.2)
       activesupport (>= 4.2.0)
+    http (5.0.4)
+      addressable (~> 2.8)
+      http-cookie (~> 1.0)
+      http-form_data (~> 2.2)
+      llhttp-ffi (~> 0.4.0)
+    http-cookie (1.0.4)
+      domain_name (~> 0.5)
+    http-form_data (2.3.0)
     i18n (1.8.10)
       concurrent-ruby (~> 1.0)
+    llhttp-ffi (0.4.0)
+      ffi-compiler (~> 1.0)
+      rake (~> 13.0)
     loofah (2.12.0)
       crass (~> 1.0.2)
       nokogiri (>= 1.5.9)
+    mail (2.7.1)
+      mini_mime (>= 0.1.1)
+    marcel (1.0.2)
     method_source (1.0.0)
+    mini_mime (1.0.3)
     mini_portile2 (2.6.1)
     minitest (5.14.4)
+    nio4r (2.5.8)
     nokogiri (1.12.3)
       mini_portile2 (~> 2.6.1)
       racc (~> 1.4)
+    noticed (1.5.7)
+      http (>= 4.0.0)
+      rails (>= 5.2.0)
     parallel (1.20.1)
     parser (3.0.1.1)
       ast (~> 2.4.1)
     pry (0.14.1)
       coderay (~> 1.1)
       method_source (~> 1.0)
+    public_suffix (4.0.6)
     racc (1.5.2)
     rack (2.2.3)
     rack-test (1.1.0)
       rack (>= 1.0, < 3)
+    rails (6.1.3.2)
+      actioncable (= 6.1.3.2)
+      actionmailbox (= 6.1.3.2)
+      actionmailer (= 6.1.3.2)
+      actionpack (= 6.1.3.2)
+      actiontext (= 6.1.3.2)
+      actionview (= 6.1.3.2)
+      activejob (= 6.1.3.2)
+      activemodel (= 6.1.3.2)
+      activerecord (= 6.1.3.2)
+      activestorage (= 6.1.3.2)
+      activesupport (= 6.1.3.2)
+      bundler (>= 1.15.0)
+      railties (= 6.1.3.2)
+      sprockets-rails (>= 2.0.0)
     rails-dom-testing (2.0.3)
       activesupport (>= 4.2.0)
       nokogiri (>= 1.6)
@@ -114,11 +193,25 @@ GEM
       simplecov_json_formatter (~> 0.1)
     simplecov-html (0.12.3)
     simplecov_json_formatter (0.1.3)
+    sprockets (4.0.3)
+      concurrent-ruby (~> 1.0)
+      rack (> 1, < 3)
+    sprockets-rails (3.4.2)
+      actionpack (>= 5.2)
+      activesupport (>= 5.2)
+      sprockets (>= 3.0.0)
     sqlite3 (1.4.2)
     thor (1.1.0)
     tzinfo (2.0.4)
       concurrent-ruby (~> 1.0)
+    unf (0.1.4)
+      unf_ext
+    unf_ext (0.0.8)
     unicode-display_width (2.0.0)
+    warning (1.2.1)
+    websocket-driver (0.7.5)
+      websocket-extensions (>= 0.1.0)
+    websocket-extensions (0.1.5)
     zeitwerk (2.4.2)
 
 PLATFORMS
@@ -129,10 +222,12 @@ DEPENDENCIES
   acidic_job!
   activejob (~> 6.1.3.2)
   activerecord (~> 6.1.3.2)
+  combustion
   database_cleaner
   minitest (~> 5.0)
+  noticed
   pry
-  railties (>= 4.0)
+  railties (>= 6.1.0)
   rake (~> 13.0)
   rubocop (~> 1.7)
   rubocop-minitest
@@ -140,6 +235,7 @@ DEPENDENCIES
   sidekiq
   simplecov
   sqlite3
+  warning
 
 BUNDLED WITH
    2.2.31

data/README.md

@@ -37,7 +37,7 @@ Or simply execute to install the gem yourself:
 
     $ bundle add acidic_job
 
-Then, use the following command to copy over the `AcidicJob::Key` migration file as well as the `AcidicJob::Staged` migration file.
+Then, use the following command to copy over the `AcidicJob::Run` migration file.
 
 ```
 rails generate acidic_job
@@ -45,16 +45,28 @@ rails generate acidic_job
 
 ## Usage
 
-`AcidicJob` is a concern that you `include` into your operation jobs.
+`AcidicJob` is a concern that you `include` into your base `ApplicationJob`.
 
 ```ruby
-class RideCreateJob < ActiveJob::Base
+class ApplicationJob < ActiveJob::Base
   include AcidicJob
 end
 ```
 
+This is useful because the module needs to be mixed into any and all jobs that you want to either make acidic or enqueue acidicly.
+
 It provides a suite of functionality that empowers you to create complex, robust, and _acidic_ jobs.
 
+### TL;DR
+
+#### Key Features
+
+* Transactional Steps — break your job into a series of steps, each of which will be run within an acidic database transaction, allowing retries to jump back to the last "recovery point".
+* Persisted Attributes — when retrying jobs at later steps, we need to ensure that data created in previous steps is still available to later steps on retry.
+* Transactionally Staged Jobs — enqueue additional jobs within the acidic transaction safely
+* Sidekiq Callbacks — bring ActiveJob-like callbacks into your pure Sidekiq Workers
+* Sidekiq Batches — leverage the power of Sidekiq Pro's `batch` functionality without the hassle
+
 ### Transactional Steps
 
 The first and foundational feature `acidic_job` provides is the `with_acidity` method, which takes a block of transactional step methods (defined via the `step`) method:
@@ -63,8 +75,10 @@ The first and foundational feature `acidic_job` provides is the `with_acidity` m
 class RideCreateJob < ActiveJob::Base
   include AcidicJob
 
-  def perform(ride_params)
-    with_acidity given: { user: current_user, params: ride_params, ride: nil } do
+  def perform(user_id, ride_params)
+    user = User.find(user_id)
+
+    with_acidity given: { user: user, params: ride_params, ride: nil } do
       step :create_ride_and_audit_record
       step :create_stripe_charge
       step :send_receipt
@@ -87,11 +101,11 @@ end
 
 `with_acidity` takes only the `given:` named parameter and a block where you define the steps of this operation. `step` simply takes the name of a method available in the job. That's all!
 
-Now, each execution of this job will find or create an `AcidicJob::Key` record, which we leverage to wrap every step in a database transaction. Moreover, this database record allows `acidic_job` to ensure that if your job fails on step 3, when it retries, it will simply jump right back to trying to execute the method defined for the 3rd step, and won't even execute the first two step methods. This means your step methods only need to be idempotent on failure, not on success, since they will never be run again if they succeed.
+Now, each execution of this job will find or create an `AcidicJob::Run` record, which we leverage to wrap every step in a database transaction. Moreover, this database record allows `acidic_job` to ensure that if your job fails on step 3, when it retries, it will simply jump right back to trying to execute the method defined for the 3rd step, and won't even execute the first two step methods. This means your step methods only need to be idempotent on failure, not on success, since they will never be run again if they succeed.
 
 ### Persisted Attributes
 
-Any objects passed to the `given` option on the `with_acidity` method are not just made available to each of your step methods, they are made available across retries. This means that you can set an attribute in step 1, access it in step 2, have step 2 fail, have the job retry, jump directly back to step 2 on retry, and have that object still accessible. This is done by serializing all objects to a field on the `AcidicJob::Key` and manually providing getters and setters that sync with the database record.
+Any objects passed to the `given` option on the `with_acidity` method are not just made available to each of your step methods, they are made available across retries. This means that you can set an attribute in step 1, access it in step 2, have step 2 fail, have the job retry, jump directly back to step 2 on retry, and have that object still accessible. This is done by serializing all objects to a field on the `AcidicJob::Run` and manually providing getters and setters that sync with the database record.
 
 ```ruby
 class RideCreateJob < ActiveJob::Base
@@ -110,7 +124,7 @@ class RideCreateJob < ActiveJob::Base
   end
 
   def create_stripe_charge
-    Stripe::Charge.create(amount: 20_00, customer: @ride.user)
+    Stripe::Charge.create(amount: 20_00, customer: self.ride.user)
   end
 
   # ...
@@ -119,20 +133,22 @@ end
 
 **Note:** This does mean that you are restricted to objects that can be serialized by ActiveRecord, thus no Procs, for example.
 
-**Note:** You will note the use of `self.ride = ...` in the code sample above. In order to call the attribute setter method that will sync with the database record, you _must_ use this style. `@ride = ...` and/or `ride = ...` will both fail to sync the value with the datbase record.
+**Note:** You will note the use of `self.ride = ...` in the code sample above. In order to call the attribute setter method that will sync with the database record, you _must_ use this style. `@ride = ...` and/or `ride = ...` will both fail to sync the value with the database record.
 
 ### Transactionally Staged Jobs
 
 A standard problem when inside of database transactions is enqueuing other jobs. On the one hand, you could enqueue a job inside of a transaction that then rollbacks, which would leave that job to fail and retry and fail. On the other hand, you could enqueue a job that is picked up before the transaction commits, which would mean the records are not yet available to this job.
 
-In order to mitigate against such issues without forcing you to use a database-backed job queue, `acidic_job` provides `perform_transactionally` and `deliver_transactionally` methods to "transactionally stage" enqueuing other jobs from within a step (whether another ActiveJob or a Sidekiq::Worker or an ActionMailer delivery). These methods will create a new `AcidicJob::Staged` record, but inside of the database transaction of the `step`. Upon commit of that transaction, a model callback pushes the job to your actual job queue.  Once the job has been successfully performed, the `AcidicJob::Staged` record is deleted so that this table doesn't grow unbounded and unnecessarily.
+In order to mitigate against such issues without forcing you to use a database-backed job queue, `acidic_job` provides `perform_acidicly` and `deliver_acidicly` methods to "transactionally stage" enqueuing other jobs from within a step (whether another ActiveJob or a Sidekiq::Worker or an ActionMailer delivery). These methods will create a new `AcidicJob::Run` record, but inside of the database transaction of the `step`. Upon commit of that transaction, a model callback pushes the job to your actual job queue.  Once the job has been successfully performed, the `AcidicJob::Run` record is deleted so that this table doesn't grow unbounded and unnecessarily.
 
 ```ruby
 class RideCreateJob < ActiveJob::Base
   include AcidicJob
 
-  def perform(ride_params)
-    with_acidity given: { user: current_user, params: ride_params, ride: nil } do
+  def perform(user_id, ride_params)
+    user = User.find(user_id)
+    
+    with_acidity given: { user: user, params: ride_params, ride: nil } do
       step :create_ride_and_audit_record
       step :create_stripe_charge
       step :send_receipt
@@ -142,7 +158,7 @@ class RideCreateJob < ActiveJob::Base
   # ...
 
   def send_receipt
-    RideMailer.with(ride: @ride, user: @user).confirm_charge.delivery_transactionally
+    RideMailer.with(user: @user, ride: @ride).confirm_charge.delivery_acidicly
   end
 end
 ```
@@ -155,10 +171,27 @@ This allows `acidic_job` to use an `after_perform` callback to delete the `Acidi
 
 ### Sidekiq Batches
 
-One final feature for those of you using Sidekiq Pro: an integrated DSL for Sidekiq Batches. By simply adding the `awaits` option to your step declarations, you can attach any number of additional, asynchronous workers to your step. This is profoundly powerful, as it means that you can define a workflow where step 2 is started _if and only if_ step 1 succeeds, but step 1 can have 3 different workers enqueued on 3 different queues, each running in parallel. Once all 3 workers succeed, `acidic_job` will move on to step 2. That's right, by leveraging the power of Sidekiq Batches, you can have workers that are executed in parallel, on separate queues, and asynchronously, but are still blocking—as a group—the next step in your workflow! This unlocks incredible power and flexibility for defining and structuring complex workflows and operations, and in my mind is the number one selling point for Sidekiq Pro.
+One final feature for those of you using Sidekiq Pro: an integrated DSL for Sidekiq Batches. By simply adding the `awaits` option to your step declarations, you can attach any number of additional, asynchronous workers to your step. This is profoundly powerful, as it means that you can define a workflow where step 2 is started _if and only if_ step 1 succeeds, but step 1 can have 3 different workers enqueued on 3 different queues, each running in parallel. Once all 3 workers succeed, `acidic_job` will move on to step 2. That's right, by leveraging the power of Sidekiq Batches, you can have workers that are _executed in parallel_, **on separate queues**, and _asynchronously_, but are still **blocking**—as a group—the next step in your workflow! This unlocks incredible power and flexibility for defining and structuring complex workflows and operations, and in my mind is the number one selling point for Sidekiq Pro.
 
 In my opinion, any commercial software using Sidekiq should get Sidekiq Pro; it is _absolutely_ worth the money. If, however, you are using `acidic_job` in a non-commercial application, you could use the open-source dropin replacement for this functionality: https://github.com/breamware/sidekiq-batch
 
+```ruby
+# TODO: write code sample
+class RideCreateJob < ActiveJob::Base
+  include AcidicJob
+
+  def perform(user_id, ride_params)
+    user = User.find(user_id)
+
+    with_acidity given: { user: user, params: ride_params, ride: nil } do
+      step :create_ride_and_audit_record, awaits: [SomeJob]
+      step :create_stripe_charge, args: [1, 2, 3], kwargs: { some: 'thing' }
+      step :send_receipt
+    end
+  end
+end
+```
+
 ## Development
 
 After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake test` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.

data/UPGRADE_GUIDE.md

@@ -0,0 +1,71 @@
+# AcidicJob Upgrade Guide
+
+1. Update version requirements in `Gemfile`
+
+```ruby
+-gem "acidic_job"
++gem "acidic_job", "~> 1.0.0.pre1"
+```
+
+result:
+```
+Installing acidic_job 1.0.0.pre1 (was 0.7.7)
+Bundle updated!
+```
+
+2. Generate migration for new `AcidicJob::Run` model
+
+```bash
+rails generate acidic_job
+```
+
+result:
+```
+create  db/migrate/#{yyyymmddhhmmss}_create_acidic_job_runs.rb
+```
+
+3. Delete any unneeded `AcidicJob::Key` records
+
+Typically, records that are already finished do not need to be retained. Sometimes, however, applications key finished records around for some amount of time for debugging or metrics aggregation. Whatever your application's logic is for whether or not an `AcidicJob::Key` record is still needed, for all unneeded records, delete them.
+
+For example, this would delete all finished `Key` records over 1 month old:
+
+```ruby
+AcidicJob::Key.where(recovery_point: AcidicJob::Key::RECOVERY_POINT_FINISHED, last_run_at: ..1.month.ago).delete_all
+```
+
+4. Migrate `AcidicJob::Key` to `AcidicJob::Run`
+
+`AcidicJob` ships with an upgrade module that provides a script to migrate older `Key` records to the new `Run` model.
+
+```ruby
+AcidicJob::UpgradeService.execute
+```
+
+This script will prepare an `insert_all` command for `Run` records by mapping the older `Key` data to the new `Run` schema. It also creates the new `Run` records with the same `id` as their `Key` counterparts, and then deletes all `Key` records successfully mapped over. Any `Key` records that were failed to be mapped over will be reported, along with the exception, in the `errored_keys` portion of the resulting hash.
+
+result:
+```
+{
+	run_records: <Integer>,
+	key_records: <Integer>,
+	errored_keys: <Array>
+}
+```
+
+5. Triage remaining `AcidicJob::Key` records
+
+If there were any `AcidicJob::Key` records that failed to be mapped to the new `Run` model, you will need to manually triage whatever the exception was. In all likelihood, the exception would be relating to the translation of the `Key#job_args` field to the `Run#serialized_job` field, as all other fields have a fairly straight-forward mapping. If you can't resolve the issue, please open an Issue in GitHub.
+
+6. Ensure all `AcidicJob::Staged` records are processed
+
+`AcidicJob` still ships with an upgrade module that provides the older `Key` and `Staged` records, so this functionality will still be present to handle any existing records in your database when you deploy the updated version.
+
+7. Remove the old tables
+
+Once you have successfully migrated everything over and the new system has been running smoothly for some time, you should drop the old `acidic_job_keys` and `staged_acidic_jobs` tables. We provide a migration generator just for this purpose:
+
+```bash
+rails generate acidic_job:drop_tables
+rails db:migrate
+```

data/acidic_job.gemspec

@@ -27,9 +27,9 @@ Gem::Specification.new do |spec|
   spec.executables = spec.files.grep(%r{\Aexe/}) { |f| File.basename(f) }
   spec.require_paths = ["lib"]
 
-  spec.add_dependency "activerecord", ">= 4.0.0"
+  spec.add_dependency "activerecord", ">= 6.1.0"
   spec.add_dependency "activesupport"
-  spec.add_development_dependency "railties", ">= 4.0"
+  spec.add_development_dependency "railties", ">= 6.1.0"
 
   # For more information and examples about making a new gem, checkout our
   # guide at: https://bundler.io/guides/creating_gem.html

data/bin/console

@@ -3,12 +3,13 @@
 
 require "bundler/setup"
 require "acidic_job"
-require_relative "../test/support/setup"
-require_relative "../test/support/ride_create_job"
 
 # You can add fixtures and/or initialization code here to make experimenting
 # with your gem easier. You can also use a different console, if you like.
 
+require_relative "../test/support/setup"
+require_relative "../test/support/ride_create_job"
+
 # (If you use this, don't forget to add pry to your Gemfile!)
 # require "pry"
 # Pry.start

data/lib/acidic_job/awaiting.rb

@@ -0,0 +1,68 @@
+# frozen_string_literal: true
+
+require "active_support/concern"
+
+module AcidicJob
+  module Awaiting
+    extend ActiveSupport::Concern
+
+    class_methods do
+      # TODO: Allow the `perform` method to be used to kick off Sidekiq Batch powered workflows
+      def initiate(*args)
+        raise SidekiqBatchRequired unless defined?(Sidekiq::Batch)
+
+        top_level_workflow = Sidekiq::Batch.new
+        top_level_workflow.on(:success, self, *args)
+        top_level_workflow.jobs do
+          perform_async
+        end
+      end
+    end
+
+    def enqueue_step_parallel_jobs(jobs, run, step_result)
+      # `batch` is available from Sidekiq::Pro
+      raise SidekiqBatchRequired unless defined?(Sidekiq::Batch)
+
+      batch.jobs do
+        step_batch = Sidekiq::Batch.new
+        # step_batch.description = "AcidicJob::Workflow Step: #{step}"
+        step_batch.on(
+          :success,
+          "#{self.class.name}#step_done",
+          # NOTE: options are marshalled through JSON so use only basic types.
+          { "run_id" => run.id,
+            "step_result_yaml" => step_result.to_yaml.strip }
+        )
+        # NOTE: The jobs method is atomic.
+        # All jobs created in the block are actually pushed atomically at the end of the block.
+        # If an error is raised, none of the jobs will go to Redis.
+        step_batch.jobs do
+          jobs.each do |worker_name|
+            # TODO: handle Symbols as well
+            worker = worker_name.is_a?(String) ? worker_name.constantize : worker_name
+            if worker.instance_method(:perform).arity.zero?
+              worker.perform_async
+            elsif worker.instance_method(:perform).arity == 1
+              worker.perform_async(run.id)
+            else
+              raise TooManyParametersForParallelJob
+            end
+          end
+        end
+      end
+    end
+
+    def step_done(_status, options)
+      run = Run.find(options["run_id"])
+      current_step = run.workflow[run.recovery_point.to_s]
+      # re-hydrate the `step_result` object
+      step_result = YAML.safe_load(options["step_result_yaml"], permitted_classes: [RecoveryPoint, FinishedPoint])
+      step = Step.new(current_step, run, self, step_result)
+
+      # TODO: WRITE REGRESSION TESTS FOR PARALLEL JOB FAILING AND RETRYING THE ORIGINAL STEP
+      step.progress
+      # when a batch of jobs for a step succeeds, we begin processing the `AcidicJob::Run` record again
+      process_run(run)
+    end
+  end
+end

data/lib/acidic_job/errors.rb

@@ -22,4 +22,6 @@ module AcidicJob
   class TooManyParametersForStepMethod < Error; end
 
   class TooManyParametersForParallelJob < Error; end
+
+  class UnknownSerializedJobIdentifier < Error; end
 end

data/lib/acidic_job/extensions/action_mailer.rb

@@ -0,0 +1,27 @@
+# frozen_string_literal: true
+
+require "active_support/concern"
+
+module AcidicJob
+  module Extensions
+    module ActionMailer
+      extend ActiveSupport::Concern
+
+      def deliver_acidicly(_options = {})
+        job = ::ActionMailer::MailDeliveryJob
+
+        job_args = [@mailer_class.name, @action.to_s, "deliver_now", @params, *@args]
+        # for Sidekiq, this depends on the Sidekiq::Serialization extension
+        serialized_job = job.new(job_args).serialize
+
+        AcidicJob::Run.create!(
+          staged: true,
+          job_class: job.name,
+          serialized_job: serialized_job,
+          idempotency_key: IdempotencyKey.value_for(serialized_job)
+        )
+      end
+      alias deliver_transactionally deliver_acidicly
+    end
+  end
+end

data/lib/acidic_job/extensions/active_job.rb

@@ -0,0 +1,39 @@
+# frozen_string_literal: true
+
+require "active_support/concern"
+
+module AcidicJob
+  module Extensions
+    module ActiveJob
+      extend ActiveSupport::Concern
+
+      concerning :Serialization do
+        class_methods do
+          def serialize_with_arguments(*args, **kwargs)
+            job_or_instantiate(*args, **kwargs).serialize
+          end
+        end
+
+        def serialize_job(*_args, **_kwargs)
+          serialize
+        end
+      end
+
+      class_methods do
+        def perform_acidicly(*args, **kwargs)
+          raise UnsupportedExtension unless defined?(::ActiveJob) && self < ::ActiveJob::Base
+
+          serialized_job = serialize_with_arguments(*args, **kwargs)
+
+          AcidicJob::Run.create!(
+            staged: true,
+            job_class: name,
+            serialized_job: serialized_job,
+            idempotency_key: IdempotencyKey.value_for(serialized_job)
+          )
+        end
+        alias_method :perform_transactionally, :perform_acidicly
+      end
+    end
+  end
+end