Is there a need for common ActiveJob job manipulation API?

I am wondering why there is (to my knowledge) no cross-adapters API in ActiveJob to handle Job manipulation after it has been enqueued.

One use case I see is for job reschedule, for instance.

class Message < ApplicationRecord
  def publish
    # Adapter specific code to remove the job if present, before re-enqueuing it
    SolidQueue::Job.where(active_job_id: active_job_id).destroy_all
    update(active_job_id: MessagePublicationJob.set(wait_until: to_be_published_at).perform_later(self).job_id)
  end
end

The previous code (one way to do it among other), is too much adapter dependant, and is not testable with the :test adapter. And is I want to change the adapter, it can be very cumbersome to look throughout the code of the entire app to change this kind of behaviour.

I would have expected to be able to call something like:

MessagePublicationJob.find(active_job_id).reschedule_at(to_be_published_at)
# or
MessagePublicationJob.find(active_job_id).cancel if active_job_id
update(active_job_id: MessagePublicationJob.set(wait_until: to_be_published_at).perform_later(self).job_id)

With the corresponding test methods #have_resheduled_job or #have_canceled_job.

Perhaps it is a bad practice to want to change/cancel an enqueued job ? If so, what’s the reason ?

If such a job API is relevant in ActiveJob, I’m available to help implement it.

2 Likes