A deferred task that creates Airbrakes every time an error occurs

Question

def perform refund_log = { success: refund_retry.success?, amount: refund_amount, action: "refund" } if refund_retry.success? refund_log[:reference] = refund_retry.transaction.id refund_log[:message] = refund_retry.transaction.status else refund_log[:message] = refund_retry.message refund_log[:params] = {} refund_retry.errors.each do |error| refund_log[:params][error.code] = error.message end order_transaction.message = refund_log[:params].values.join('|') raise "delayed RefundJob has failed" end end 

When I call "delayed RefundJob failed" in the else statement, it creates Airbrake . I want to run the task again if it ends in the else section.

Is there a way to reorder a task without raising an exception? And prevent the creation of an air brake?

I am using delayed_job version 1.

Answer 1

The cleanest way is to reorder, i.e. create a new task and place it in the queue, and then exit the method in normal mode.

Answer 2

To clarify @Roman's answer, you can create a new task with the retry parameter in it and put it in the queue.

If you support the retry parameter (increase it every time you re-run the task), you can keep track of how many attempts you have made, and thereby avoid an infinite loop of retries.

Answer 3

DelayedJob expects the job to raise the error required by definition.

From there you can:

• Ignore your performance on the air brake side, see https://github.com/airbrake/airbrake#filtering so that it still queues again without filling out your logs
• Immerse yourself in the DelayedJob code, where you can see at https://github.com/tobi/delayed_job/blob/master/lib/delayed/job.rb#L65 that there is a method called reschedule run_with_lock ( https: // github. com / tobi / delayed_job / blob / master / lib / delayed / job.rb # L99 ). From there, you can reschedule it manually, instead of raising your exception.

On a later decision, I suggest adding some mechanism that still fills the air brake report on the third or later attempt, you can still find that something is wrong, without the hassle, when your logs are filled with attempts.