frontend-patterns/research/bench/infospaces/kubernetes-stale-writes-01/artifacts/generated/candidates.md

P01 Optimistic Concurrency Rejection

Definition

A client attempts to update a resource by providing a version identifier. The server rejects the update with a conflict error if the provided version identifier does not match the server's current version of the resource.

Candidate Identity

P01, family: Concurrency Control, scale: Interaction, status: draft, maturity: hypothesis, evidence_kind: primary

Context

A client holds a local representation of a resource, including a version identifier obtained from a previous read operation. The client then attempts to modify this resource and send the updated state to the server.

Problem

Without a mechanism to detect concurrent modifications, a client's update based on an outdated view could inadvertently overwrite changes made by another client, leading to data loss or inconsistent states.

Forces

• Preventing data loss: The system needs to ensure that changes made by one client are not silently overwritten by another client's update based on an older state.
• Client autonomy: Clients should be able to propose updates without constant server synchronization, allowing for disconnected work or reduced network traffic.

Solution

When a client sends an update request for a resource, it includes a resourceVersion (C01). The server compares this resourceVersion with its current version of the resource. If they do not match, indicating that the resource has been modified since the client last read it, the server rejects the update with a 409 Conflict error (C01, C02).

Dynamics

1. Client fetches resource R, receiving resourceVersion V1.
2. Client modifies R locally.
3. Another client (or process) updates R on the server, changing its resourceVersion to V2.
4. Client attempts to update R, sending its modified R along with resourceVersion V1.
5. Server compares V1 with its current resourceVersion V2.
6. Since V1 != V2, the server returns a 409 Conflict error.

Resulting Context

The client receives a 409 Conflict error, indicating that its proposed update could not be applied due to a concurrent modification. The server's state remains unchanged.

Consequences

• Data integrity: Prevents accidental overwrites of concurrent changes.
• Client responsibility: The client is informed of the conflict and must decide how to resolve it (e.g., fetch the latest version, reapply changes, or notify the user).
• Increased complexity for clients: Clients must implement logic to handle 409 Conflict responses, which often involves re-fetching the resource and re-attempting the update.

Failure Modes

• Client ignores conflict: If the client does not handle the 409 Conflict error, the update will simply fail without resolution.
• Incorrect versioning: If the resourceVersion mechanism is flawed or not consistently applied, conflicts might not be detected.

Source Evidence

• C01: "If a client submits an update to a resource using a resourceVersion that is no longer current, the Kubernetes API server responds with a 409 Conflict error." (SRC-0008, Updates to existing resources, second paragraph)
• C02: "The Kubernetes API server uses a 409 Conflict HTTP status code to indicate that a client's proposed update is based on an outdated resourceVersion." (SRC-0008, Updates to existing resources, second paragraph)

Counterevidence

None.

Review Notes

The evidence clearly describes a server-side mechanism for optimistic concurrency control using a version identifier and a specific HTTP status code for rejection.

Known uses

Known uses: unknown Recurrence: unknown

{"candidates": [{"id": "P01", "known_uses": [], "recurrence": "unknown"}]}