지연된 작업으로 인해 오류가 발생할 때마다 에어 브레이크가 생성됩니다.

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 

else 문에서 "delayed RefundJob has failed"를 발생 시키면 Airbrake이 생성됩니다. else 섹션에서 끝나면 작업을 다시 실행하고 싶습니다.

예외를 발생시키지 않고 작업을 다시 대기시킬 수있는 방법이 있습니까? 그리고 에어 브레이크를 만들지 못하게합니까? 내가 delayed_job 버전 1.

Answer 1

DelayedJob을 사용하고

는 작업이 정의에 의해, 다시 대기열에 오류를 올릴 것으로 기대하고있다.

거기에서 다음 중 하나를 수행 할 수 있습니다 :

• 은 어디 https://github.com/tobi/delayed_job/blob/master/lib/delayed/job.rb#L65에 볼 수 있도록 여전히 DelayedJob 코드로 로그를
• 다이빙을 채우지 않고 다시 큐에 도착 https://github.com/airbrake/airbrake#filtering를 참조하십시오 에어 브레이크 측에 execpetion 무시 방법 일정이이고 사용할 수 있으며 run_with_lock (https://github.com/tobi/delayed_job/blob/master/lib/delayed/job.rb#L99)으로 사용됩니다. 거기에서 예외를 제기하는 대신 수동으로 다시 일정을 호출 할 수 있습니다.

나중에 해결책에 관해서는 세 번째 또는 나중의 시도에서 에어 브레이크 보고서를 채우는 메커니즘을 추가하는 것이 좋습니다. 시도로 인해 로그가 가득 차는 번거 로움없이 여전히 문제가 있음을 감지 할 수 있습니다.

Answer 2

가장 깨끗한 방법은 새 작업을 만들고 대기열에 추가 한 다음 정상적으로 종료하는 것입니다.

Answer 3

@ Roman의 응답에 대해 자세히 설명하려면 retry 매개 변수를 사용하여 새 작업을 만들고이를 대기열에 추가 할 수 있습니다.

retry 매개 변수를 유지하면 (작업을 다시 대기열에 추가 할 때마다 증가시킵니다) 재 시도 횟수를 추적 할 수 있으므로 무한 재 시도 루프가 발생하지 않습니다.