Put the precondition inside the object write

Suppose two publishers both read the same manifest, compute different successors, and then PUT them unconditionally. Strong consistency of each individual operation does not prevent one successful write from replacing the other. The application performed no atomic check that the manifest was still the observed state. Serializing the local code in one process does not fix competition from other processes or recovery workers. Move the predicate to a supported conditional API or use another coordination protocol.

In S3 general purpose bucket examples, If-None-Match with the wildcard can create only when the relevant current object does not exist, and If-Match compares the supplied ETag with the current object's validator for supported writes such as PutObject and CompleteMultipartUpload. Permission, signing, and API support still apply. In a versioned bucket, a current delete marker has the documented absence semantics for the create condition; an older retained version does not necessarily block creation of a new current object.

Treat a returned ETag as an opaque value unless the exact upload and encryption contract documents a stronger interpretation. Multipart uploads and some encryption configurations do not produce a simple whole-object MD5 ETag. Even when an ETag matches a content digest in a particular case, it should not be promoted to a general-purpose version counter. Use an explicit supported checksum field and algorithm for integrity, and an actual version identifier or application revision protocol when historical identity matters.

Equality also has an ABA limitation: if content changes from A to B and back to an ETag-equivalent A, a predicate based only on that current validator may pass despite the intervening history. Some metadata changes can likewise fall outside what the ETag represents. The needed invariant might only be replace these current bytes, in which case that condition can suffice; another invariant may require no intervening revision. State which one the application needs and select evidence that actually expresses it.

A precondition failure tells the client its expected current state did not satisfy the write predicate. Read the new state and deliberately recompute, merge, or abandon rather than deleting the condition to make a retry succeed. Concurrent deletion and multipart operations have additional documented error cases and recovery requirements, so distinguish a failed predicate from a transport timeout with an unknown outcome. Store operation evidence needed to recognize whether the intended update already became visible.

The probability lab illustrates contention only under a synthetic independent-attempt model. Reset, set both p=0.3 as an assumed probability an attempt loses its precondition race and n=10, predict the number-of-conflicts distribution, then Play or Step. The lab does not execute compare-and-write operations or model retry feedback. Real publishers can synchronize and contend repeatedly, violating independence. Its bars help interpret an assumed failure count; they cannot certify a lock, a unique history, or a safe retry policy.