Using Good Job to track all ActiveJob executions, even those with perform_now

[houdinisparks]

Hi there!

We would like to extend GoodJob to also track executions made by perform_now jobs, and would like to find out how we can create a GoodJob record manually without enqueuing it for any processing. This is what we did for now:

# on app/jobs/application_job.rb

  after_perform do |job|
    good_job = GoodJob::Job.find_by(active_job_id: job.job_id)

    if good_job.present?
      good_job.update(serialized_params: good_job.serialized_params.merge(
        {
          METADATA_KEY => job.metadata&.deep_symbolize_keys,
        }
      ))
    else
      # Only executed if job ran with 'perform_now'. Good Job table will be used as the
      # source of truth for all executions that ran with ActiveJob. Visualized using Good Job's dashboard.
      GoodJob::Job.create!(
        active_job_id: job.job_id,
        serialized_params: job.serialize
      ).tap do |job|
        job.discrete_executions.create!(
          created_at: Time.zone.now,
          finished_at: Time.zone.now
        )
      end
    end
  end

For every job execution, and after_perform hook will be used to check for the existing of a good job record, if none is found, it will create one that mocks a "finished" job. No retrigger for this job should be allowed, it purely stays just as a reference.

Any concerns with this approach?

[bensheldon]

This isn't my favorite. I guess it works, but I imagine you'll have to keep that in sync with changes in GoodJob and it would be brittle. Still brittle, but one less of a database lookup, you could access GoodJob::CurrentThread.job to determine both if you're in a GoodJob executor and... [grimaces] ... mutate it 😅

Can I ask why you want to track perform_now?

What I usually see from folks is that they want to tie some aspect of their application/business logic to the job queue (e.g. User has_many Jobs) and I discourage that. The Job records are optimized around keeping a high performance queue. If you do need to do application-level book keeping of what's happened, I'd recommend you instead made your own Task-like model, and tracked it separately rather than overloading GoodJob to associate with your application.