"Repeat delivery; preserve one intended effect."
Define one intended effect
Networks repeat themselves. A tap can be delivered twice, a timeout can hide a success, and a worker can restart after writing output but before acknowledging it. Retry is normal; duplicate effect is the bug.
Retry the same durable row
Current Inkwell retries a failed durable job by moving that same row back to queued. The guarded update is a no-op for queued, running, or done work, so a repeated retry command cannot spawn another job.
Do not confuse retry with another request
Treating every retry as a new job can produce competing translations. Voice is on-demand and is not represented by a durable job. Source edits supersede pending review work rather than hiding a second identity inside the retry command.
Put crashes on the timeline
Test “Retry Without Duplication” on a timeline where the process may disappear before acceptance, after commit, after claim, after the external call, or after output storage. At every cut, state what the database knows. A repeated request must not duplicate cost or prose.
Design it
Design retry handling for the case where the client timed out after the server committed. Name statuses, timestamps, and attempt rows. Explain which evidence authorizes recovery instead of letting a cleanup script guess.
Observability is recoverability
An operator should distinguish queued, running, failed, and done with one query and know the next safe action. A silent unknown called a queue has already lost the work.