2017-08-14 15 views
4

私は、約束が結ばれていて、何か問題が生じた場合にリアルタイムデータベースを更新する必要があるときに、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すると行われる書き込みをするように見えるとして例を見つけることができませんでしたよね。 (現実の世界ではそれほどではありません)

+0

実際にコード内でエラーを処理できるのは、エラーを検出するだけです。だから、あなたは間違って、キャッチを引き起こすと思いますか?どのようにそれを処理したいですか? –

+0

Btw:現在のところ、クラウド機能を強制的に再試行する方法はありませんが、将来のバージョンで追加される可能性があります。 –

+0

AWSラムダのPDFを作成し、クラウドストレージに書き出し、正しく書かれていることを確認して開くことができます。書かれたPDFが添付された郵便番号を使用してメールを送信し、それに従ってデータを更新します。 おそらくすべてのhttps呼び出しなどの再試行を設定できますが、作業量とテスト量は多すぎます。 idempodentコード(再試行の実装方法に関係なく)を書いたほうがずっと簡単で、全体を再試行するだけです。 サービスが停止し、一時的なエラーコードが表示されたり、クラウドストレージへの書き込みが破損して終了することがありました。 – anotherdev

答えて

2

[Firebaseのクラウド機能のデベロッパー] あなたのアイデアはかなり巧妙です。これは何度も動作しますが、データベースが利用できないような低レベルの問題や、アプリケーションのタイムアウトを捕まえることはありません(ただし、再試行をエンキューするPromise.raceで修正可能です)。

私たちは、コア製品にリトライを追加する作業を進めています。あなたが問題を提起して以来、私は顧客からの意見を募集したいと思っています。開発者は、リトライポリシーでどのような機能が必要ですか?あなたは元気なデフォルトと思われますが、どのようにそのデフォルトを上書きすると思いますか?

+0

私たちはチェックインのcronジョブを持っているので、xより古いワークキューエントリに触れて、データベースのトリガーを再トリガーすることになるので、実際にはアプリケーションはオフラインなどでOKです.xは推定最悪値の25倍ですケース実行時間。このようにして、「落とした」ワークキューエントリをキャッチし、最終的に一貫性を保ちます。そこでは大部分のアイテムが本当に素早く処理されます。 – anotherdev

+0

ウィッシュリストに関しては、ここで説明します:私は、関数ごとの再試行ポリシーがgraballyバックオフし、再試行回数が限界(デフォルト)5を超えた場合に断念するのが大好きです。バックオフアルゴリズムはおそらく指数関数的なので、残りは比較的ゆっくりとした間隔でゆっくりとしています。未知の例外がある場合は自動再試行を追加するには遅すぎるのかどうかは分かりませんが、手動ですべてを承認するようにオプトインする方法が必要です。これはPub/Subトリガーにも実装する必要があります。現時点ではあまりにも信頼性がありません:/ – anotherdev

+0

そして素晴らしい作業に感謝します! FirebaseのCFはすばらしい製品に進化しています! – anotherdev

関連する問題