Customize the parent class of SolidQueue::RecurringJob

[tmimura39]

Introduction

Allow specifying recurring tasks just with a "command" I find this feature very interesting.

However, there is one barrier to its use. That is, the parent of SolidQueue::RecurringJob is fixed at ActiveJob::Base.

I have defined error handling in ApplicationJob as described below. https://github.com/rails/solid_queue/blob/67b964d5e9d1120e0f198dc1ef538a0aff966133/README.md#error-reporting-on-jobs

This error handling does not work when using “command”.

Proposal

How about allowing customization of the SolidQueue::RecurringJob parent class?

Thinking something similar to MaintenanceTasks.parent_controller. https://github.com/Shopify/maintenance_tasks/blob/d98544fb3de714a14082b64e6831980945db01cf/README.md#customizing-the-parent-controller-for-the-web-ui

What do you think?

Workaround

Just extend SolidQueue::RecurringJob.

module JobErrorHandling
  extend ActiveSupport::Concern

  included do
    rescue_from(Exception) do |exception|
      Rails.error.report(exception)
      raise exception
    end
  end
end

class ApplicationJob < ActiveJob::Base
  include JobErrorHandling
end

Rails.application.config.after_initialize do
  SolidQueue::RecurringJob.include(JobErrorHandling)
end

[rosa]

Yes, good idea! I'll get this done shortly. I could also allow providing the job class to be used in this case 🤔 Like config.action_mailer.delivery_job.

[tmimura39]

Thanks for the response 😄 Yes, such an approach would be more flexible. However, we could not determine if it was the optimal solution 🤔

I have considered the use case of being able to specify our own Job class.

config.solid_queue.recurring_command_job = "MyRecurringCommandJob"

Allows defining processes other than eval(command)

For example, like this

class MyRecurringCommandJob < ActiveJob::Base
  def perform(command)
    eval(command)
    # something...
  end
end

I believe the "command" pattern is important for its simplicity, "just execute the command". In such a case, it would be better to specify class and args as usual, since this is different from the idea of the "command" pattern.

Allows defining config restricted to jobs executed by "command"

For example, like this

class MyRecurringCommandJob < SolidQueue::RecurringJob
  # Error handling for "command" only
  rescue_from(Exception) do |exception|
    # something
    raise exception
  end

  # Collback for "command" only
  around_perform :something

  # queue for "command" only
  queue_as :solid_queue_command_recurring
end

Mostly I would consider error handling equivalent to RecurringTasks that do not utilize "command". The same goes for callbacks and queue.

Allows changing the parent class

For example, like this

class ApplicationJob < ActiveJob::Base
  rescue_from(Exception) do |exception|
    Rails.error.report(exception)
    raise exception
  end
end

class MyRecurringCommandJob < ApplicationJob
  def perform(command)
    eval(command)
  end
end

Yes, this is my use case. This will still accomplish what I want to do, but I need to copy SolidQueue::RecurringJob#perform. It is a simple copy, but we will need to keep up with future updates to SolidQueue.

Given these considerations, I thought the best solution would be to allow the SolidQueue::RecurringJob parent class to be customized.

However, these are just my own thoughts. There may be many other use cases that I cannot imagine. It would be a good choice to allow customization of the Job class to cater to all of them. It is also community friendly to put action_mailer.delivery_job and settings together.

Also, I am in no hurry to implement the feature, as my use case can be accomplished with “Workaround” as well. I hope you will carefully consider this and choose the better solution.

thanks :+1:

[tmimura39]

I just noticed that you already have the ability to customize a job class 👀 (I don't know if this is an official config 🙃)

Rails.application.config.after_initialize do # or to_prepare
  SolidQueue::RecurringTask.default_job_class = MyRecurringCommandJob
end

[rosa]

Oh wow, yes, it is! 🤣 I added this ages ago when I first started implementing this feature. Then, I had to work on other non-solid queue stuff at work, and came back to it recently. I had completely forgotten I had added that! 🤣 I also forgot to expose it or document it 😅 I think this could work! My initial idea was to also allow people to do different things with their command parameter.