35 lines
1.6 KiB
Markdown
35 lines
1.6 KiB
Markdown
|
---
|
|||
|
|
title: Version-Checked Mutation
|
|||
|
|
status: draft
|
|||
|
|
maturity: hypothesis
|
|||
|
|
families: [mutation, authority]
|
|||
|
|
scales: [L2, L6]
|
|||
|
|
admission: research-candidate-only
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Version-Checked Mutation
|
|||
|
|
|
|||
|
|
Context: a proposal depends on a previously observed record. Problem: concurrent
|
|||
|
|
updates can invalidate that base. Consistency competes with throughput and user effort.
|
|||
|
|
|
|||
|
|
Proposed solution: send an expected version with the proposal; the authority checks
|
|||
|
|
it atomically with validation and commit. A mismatch rejects the attempt. Preserve
|
|||
|
|
the draft, fetch current state and reconsider intent before a new attempt. An
|
|||
|
|
operation identity for safe retries is separate from the version precondition.
|
|||
|
|
|
|||
|
|
Consequences: lost updates can be detected, but high contention creates repeated
|
|||
|
|
review. Unconditional or commutative operations may need different preconditions;
|
|||
|
|
blindly retrying with a new version can overwrite another user's intent.
|
|||
|
|
|
|||
|
|
Evidence: T01 documents Kubernetes conditional PUT; T02 documents a different GitLab
|
|||
|
|
failure surface and optional last_commit_id, insufficient to prove identical atomic
|
|||
|
|
semantics. One precise mechanism use, not two verified frontend uses. Recurrence of
|
|||
|
|
this frontend configuration: unknown. Hypothesis only.
|
|||
|
|
|
|||
|
|
Proposed connection: rejection creates work for [Local Draft State](LocalDraftState.md)
|
|||
|
|
and [Mutation Outcome Tracking](MutationOutcomeTracking.md).
|
|||
|
|
|
|||
|
|
T01–T05 refer to [TransactionalEvidenceExpansion](../reviews/TransactionalEvidenceExpansion.md).
|
|||
|
|
Connections are research proposals, not admitted graph edges.
|
|||
|
|
Reasoning exercise: [VC-01](../walkthroughs/VC01-TransactionalAdministration.md).
|