Class: Plutonium::Interaction::Async::ReapJob

Inherits:
ActiveJob::Base
  • Object
show all
Defined in:
lib/plutonium/interaction/async/reap_job.rb

Overview

Resumes runs stuck pending/running long past their last recorded activity — a worker crash mid-batch, or a job the queue silently dropped.

Resetting to "pending" and re-enqueuing is safe, not a replay: the executor resumes from Run#unhandled_target_ids, so a target already dispositioned before the interruption is not redone.

This is still a heuristic on TIME, not a true lease: a run that is merely slow (not dead) and crosses stall_after gets resumed too. What bounds that is lock_version — see #reap. The resumed row's version no longer matches the live worker's, so the live worker stops at its next write rather than racing. Two things that does NOT do: it cannot interrupt an in-flight perform_on (a target may be applied twice, once by each side), and it cannot roll back what the superseded worker already committed. Set stall_after well above this app's slowest legitimate run.

Hosts must schedule this themselves (a periodic job / cron task), same as Wizard::SweepJob.

Instance Method Summary collapse

Instance Method Details

#perform(stall_after: Plutonium.configuration.async_interactions.stall_after) ⇒ Object 



39
40
41
42
43
 
# File 'lib/plutonium/interaction/async/reap_job.rb', line 39

def perform(stall_after: Plutonium.configuration.async_interactions.stall_after)
  threshold = stall_after.ago

  Run.stalled(before: threshold).find_each { |run| reap(run, threshold) }
end