Clarify mutation eligibility across replay
This commit is contained in:
parent
e5ab04d49c
commit
900ceb422c
1 changed files with 3 additions and 0 deletions
|
|
@ -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
|
||||
exact replay has the original effect; a changed worker, fence, payload, stale,
|
||||
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
|
||||
operation ledger around an abstract successful `JobProtocol` effect. It does
|
||||
|
|
|
|||
Loading…
Reference in a new issue