用於Firebase錯誤處理的雲端函數

我想知道當我有鏈接承諾時編寫node.js代碼的正確方法是什麼，如果出現錯誤，我需要更新實時數據庫？用於Firebase錯誤處理的雲端函數

下面是代碼：

export const testErrorHandling = functions.database 
     .ref('/workqueue/{pushId}/something').onWrite(event => { 

    // Exit when the data is deleted. 
    if (!event.data.exists()) { 
    return; 
    } 

    //This is the retry count, give up if more than 5 times have been retried. 
    const data = event.data.val() 
    if (data.count >= 5) { 
    return 
    } 

    return event.data.ref.root.child(data.fulluri).once('value').then(snapshot => { 
    //Process all, if ok, delete the work queue entry 
    return event.data.ref.remove() 
    }).catch(exception => { 
    console.log('Error!: ' + exception) 

    //Log error, increase retry count by one an write to that 
    //location to trigger a retry 

    //Is the line below OK? 
    //return event.data.ref.child('count').set(data.count + 1) 
    }) 

})

我想這是在許多情況下常見的需求，但是因爲所有的例子似乎只是寫console.error並做不能找到一個例子。（在現實世界很少。）

來源

2017-08-14 anotherdev

只有在代碼中實際處理它們時，才應該發現錯誤。那麼你期望出現什麼問題會引發這個問題呢？你想怎麼處理它？ –

順便說一句：目前沒有辦法強制在雲端函數中重試，但它可能會在未來版本中添加。 –

我們正在AWS Lambda上創建一個PDF，將其寫入雲存儲，確保其寫入正確並可以打開，使用包含書面PDF作爲附件的郵戳發送電子郵件並相應地更新數據。我們可以設置重試所有的https調用等，但工作量和測試有點太多。編寫idempodent代碼（它必須是不管如何實現重試）並重試整個過程要容易得多。因此，通常我們看到服務停止運行，導致臨時錯誤代碼或最終導致雲存儲寫入損壞 – anotherdev

[Firebase雲功能開發人員] 您的想法非常聰明。它將工作很多次，但不會捕獲較低級別的問題，例如數據庫不可用或者應用程序超時（儘管可以使用Promise.race來排除重試）。

我們正在努力爲核心產品添加重試次數。既然你提出了這個問題，我很樂意徵求一些客戶的意見。作爲開發人員，您在重試策略中需要/期望哪些功能？你覺得什麼是一個理智的默認值，你會如何覆蓋這些默認值？

來源

2017-08-14 18:59:46

實際上我們確定應用程序處於脫機狀態等等，因爲我們打算有一個checkup cron作業，它接觸到任何比x更早的workqueue條目，導致重新觸發數據庫觸發器，其中x是估計的最差的25倍案件執行時間。通過這種方式，我們可以捕獲任何「丟棄」的工作條目，並最終保持一致，其中大部分項目處理得非常快。 – anotherdev

至於願望清單，這裏是：我很想看到每個功能重試策略，如果重試次數超過限制（默認），則會逐漸退出並放棄。5.退避算法可能是指數級的，所以應該快速完成對夫婦，並且其餘相對較慢，間隔較大。我不知道如果添加自動重試如果有未捕獲的異常是太遲了，但應該有一種方法來選擇手動確認一切正常。這是一個需要實施Pub/Sub觸發器的要求，因爲它目前太不可靠：/ – anotherdev

並感謝您的出色工作！ Firebase的CF正在發展成爲一款令人驚歎的產品！ – anotherdev

用於Firebase錯誤處理的雲端函數

回答

相關問題