私は2つのシナリオを見ていました：Aは大丈夫です、Bはわかりません。
シナリオA：コミット後、ディスパッチ前にアプリケーションの再起動をシミュレートする
コミットされたイベントは、手順5で再度送信されます。これは正常に機能し、ディスパッチャコードでも確認できます。
シナリオB：バスエラーをシミュレートする
この場合、動作を見つけることができず、それが有効なケースであるかどうかも疑問に思います。これは、バスコードにバグがあった場合にのみ発生する可能性があります。
ディスパッチを再試行するトリガーはありますか、それともこれを処理するためのコードを記述する必要がありますか、それとも私の推論に誤りがありますか？
シナリオAの評価は正しく、アプリケーションやマシンの再起動/プロセスの終了などの障害状態では、プロセスが再起動すると、ディスパッチされていないコミットが検出され、ディスパッチャーにプッシュされます。
シナリオBはやや注意が必要です。問題は、EventStoreがバスではないため、バス内のエラーを処理する方法の問題は、EventStore自体では処理できないものではないということです。さらに、バスの実装は多数あるため、EventStoreを特定の実装に結合したくありません。一部のユーザーはメッセージバスさえ使用しないかもしれません。代わりにRPC呼び出しを使用することを決定する場合があります。
その場合、あなたが本当に抱えている問題は、バスの障害、ひいてはキューの障害をどのように処理する必要があるかということです。EventStoreにはインターフェイスIPublishCommitsがあります。イベントがコミットされると、ディスパッチャにプッシュされます。ディスパッチャは、IPublishCommitsの実装によってイベントが適切かつ正常に処理された後、イベントをディスパッチされたものとしてマークする責任があります。
一時的なバスとキューの障害を処理する最良の方法は、IPublishCommits実装に回路ブレーカーパターンを実装することです。このパターンは、動作が再開するまで再試行します。シリアル化の失敗などのより大きな問題については、管理者にすぐに通知するある種の重大な失敗をログに記録することをお勧めします。繰り返しになりますが、これらすべての厄介な問題は、EventStoreが状況のすべての詳細を知ることができないことです。