延遲創建Airbrakes每次它引發錯誤

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語句中引發「延遲RefundJob失敗」，它創建一個Airbrake。如果它在else部分結束，我想再次運行該作業。延遲創建Airbrakes每次它引發錯誤

有什麼辦法可以在不引發異常的情況下重新排隊工作嗎？並防止創建一個airbrake？

我使用delayed_job的版本1.

來源

2012-10-09 Syed Usamah

DelayedJob預計工作提高一個錯誤重新排隊，由定義。

在那裏，您可以：

忽略對空氣制動側的execpetion，看到https://github.com/airbrake/airbrake#filtering所以還是得排隊，無需再次填寫你的日誌
潛入DelayedJob代碼在那裏你可以https://github.com/tobi/delayed_job/blob/master/lib/delayed/job.rb#L65一個看方法名爲reschedule可用並由run_with_lock（https://github.com/tobi/delayed_job/blob/master/lib/delayed/job.rb#L99）使用。從那裏你可以調用手動重新安排它，而不是提高你的例外。

關於以後的解決方案，我建議加入一些機制仍然填補第三的空氣制動報告或稍後再試，仍然可以檢測到什麼是錯的，而無需你的日誌在嘗試填補的麻煩。

來源

2012-10-10 12:55:39 jhchabran

謝謝您的詳細解答。關於重新安排方法，我的印象是當工作失敗時重新安排時間（如果我沒有提出錯誤，我會通過）。我在這裏糾正了嗎？ –

最簡潔的方法是重新排隊，即創建一個新的作業併入隊，然後正常退出該方法。

來源

2012-10-10 16:47:43 Roman

問題在於新工作可能最終會在else循環中（就像開始時那樣），這意味着我將不得不創建第三級工作，等等。 –

沒錯。這種方法有什麼問題？ – Roman

要詳細說明@ Roman的回覆，您可以創建一個新作業，其中包含一個retry參數，並將其排入隊列。

如果您維護retry參數（每次您重新入隊作業都增加一個參數），您可以跟蹤您所做的重試次數，從而避免無盡的重試循環。

來源

2014-04-08 14:22:22

延遲創建Airbrakes每次它引發錯誤

回答

相關問題