ms2k/remora
SHA256
Watch
0
Code Releases Activity

Clarify mutation eligibility across replay

Browse source
This commit is contained in:
ms2k 2026-07-13 18:33:42 +09:00
commit 900ceb422c
1 changed files with 3 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

3
docs/spec/api/README.md
View file

@ -25,6 +25,9 @@ Renew, progress, and outcome use attempt ID, fencing token, worker incarnation,
and `operation_id`. Each operation identity retains a request fingerprint. An and `operation_id`. Each operation identity retains a request fingerprint. An
exact replay has the original effect; a changed worker, fence, payload, stale, exact replay has the original effect; a changed worker, fence, payload, stale,
or non-authoritative tuple returns `precondition_failed` without mutation. or non-authoritative tuple returns `precondition_failed` without mutation.
First observation is accepted only when the corresponding `JobProtocol` action
is enabled. Later eligibility changes do not alter a stored response, while a
fresh operation is evaluated against current eligibility.
[`RemoraApiMutation`](../../protocol/RemoraApiMutation.tla) models this durable [`RemoraApiMutation`](../../protocol/RemoraApiMutation.tla) models this durable
operation ledger around an abstract successful `JobProtocol` effect. It does operation ledger around an abstract successful `JobProtocol` effect. It does