--- title: "What an S3 Write Precondition Changes When Two Publishers Update One Artifact" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/s3-conditional-write-current-etag-lost-update" last-updated: "2026-10-20" --- # What an S3 Write Precondition Changes When Two Publishers Update One Artifact Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. For an existing S3 artifact, an If-Match write conditions replacement on the current object's ETag matching the supplied value. A mismatch can reject a publisher's stale proposal even when its earlier read was accurate. Strong read consistency supplies faithful observations; the write precondition connects a later replacement to an expected state. Assess whether the proposed publishing interface actually checks that state during the write, and what a rejected update leaves unresolved. ## An accurate read leaves a later replacement exposed An artifact publisher may read a manifest, change one field and submit a replacement. Another publisher can do the same before either replacement is stored. Both initial reads can accurately describe the same current object. The potential loss appears later, when one replacement displaces the other. AWS describes strong read-after-write consistency and atomic updates to a single S3 key. Readers receive a whole object value. Those properties remain useful: after a completed write, a subsequent read reflects it in the absence of further writes. They do not make an earlier observation a condition on a later unconditional replacement. RFC 9110, published in June 2022, describes If-Match as a precondition used to avoid lost updates. The relevant change is where the comparison takes effect: at the state-changing operation, rather than only in a preliminary read. The concrete behavior below is S3 PutObject as documented on October 20, 2026. References: [A1](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel), [R1](https://www.rfc-editor.org/rfc/rfc9110.html), [A2](https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html) ## Follow two different proposals from the same starting manifest Consider one existing manifest.json key in an unversioned, general purpose S3 bucket. Initially its body selects model release M1 and dataset D1, with opaque ETag A. Editor One and Editor Two independently read that body and A before any replacement occurs. A and B below are symbolic tags, not digest values or revision numbers. Editor One proposes a body selecting M2 and D1. Editor Two independently proposes M1 and D2. Each has retained the other field from its starting copy. The application wants both proposed changes considered; this example makes no claim that M2 and D2 are compatible. First stipulate that Editor One's PutObject with an If-Match condition for A succeeds. Its replacement becomes current and has ETag B, different from A. Only after that success does Editor Two submit its different body, still conditioned on A. S3 compares A with current B, returns 412 Precondition Failed and leaves Editor One's body in place. There are exactly two replacement attempts and one successful replacement. The stored selection remains M2 and D1; Editor Two's D2 proposal has not been incorporated. There are no deletions, intervening writes, historical-version selections or other failures in this example. AWS separately documents 409 conflicts and 404 outcomes involving a missing object or concurrent deletion; 412 is not a universal result for every competing operation. In a separate comparison, keep the same starting reads and first successful replacement but make Editor Two's later replacement unconditional and successful. Its body selecting M1 and D2 then replaces the body selecting M2 and D1, losing Editor One's model selection from the current manifest. Strong consistency has not failed: subsequent reads faithfully expose the later replacement. The omitted predicate is what allowed that stale proposal to replace the current body. References: [A2](https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html), [A3](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html), [A1](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel) ## Choose the predicate that matches the publication decision For the unversioned case considered here, S3 documents If-None-Match with an asterisk as a create-only condition: the key must not already exist. In the worked example, manifest.json already exists, so this existence condition would reject a replacement even before the editors diverged. If-Match with the observed ETag addresses replacement of that existing artifact. The distinction matters when a supplier describes an interface only as supporting conditional writes. Ask whether its condition tests absence or the expected ETag of the object being replaced. Those predicates answer different questions. References: [A3](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) ## Read the ETag as an equality value, not a history counter For this comparison, treat the ETag as an opaque value. AWS states that an S3 ETag reflects object contents rather than metadata and is not universally an MD5 digest. Multipart creation and some encryption cases prevent that checksum interpretation. Matching the tag does not require interpreting it as a whole-file checksum. Nor does matching A prove that no write has occurred since A was observed. A current-value equality test does not enumerate intervening states or supply a monotonically increasing revision. If the current tag matches A again, that equality alone provides no complete history. The tested value also supplies no comparison of metadata or access-control-list state. If the publishing requirement includes those properties, an ETag match leaves that part of the requirement unestablished. The related S3 ETag and checksum guide addresses byte-integrity evidence in detail. References: [A4](https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html), [R1](https://www.rfc-editor.org/rfc/rfc9110.html) ## A rejected update preserves a decision for the application In the example, rejection prevents Editor Two from silently discarding Editor One's change. It does not decide which release and dataset should be selected. A body selecting M2 and D2 would be a third proposal whose validity remains an application question. The condition has performed no semantic merge. A retry token addresses a different issue: which repeated attempts the selected API recognizes as the same operation. The two editors have different intended updates, so duplicate-attempt handling alone supplies no comparison with the manifest's current ETag. HTTP PUT being idempotent likewise does not reconcile two different replacement bodies. The related retry-key guide explains operation and scope boundaries. Finally, the condition is on one manifest object. It does not validate the referenced model or dataset, make their updates atomic with the manifest, or establish a complete usable release. The related S3 consistency and dataset-release guide addresses that wider boundary. References: [R1](https://www.rfc-editor.org/rfc/rfc9110.html), [A1](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel) ## Ask the supplier to account for the stale contender For a shared-artifact publishing proposal, ask the appointed application or storage provider to identify the exact object being replaced, the state value the publisher observed, and the predicate evaluated during replacement. An initial read record establishes an observation; it does not demonstrate that the later write carried that condition. The useful explanation follows both different proposals through their outcomes. Which body becomes current? What happens to the contender still expecting A? How is its unincorporated change presented for a decision? The account should show which edit remains unincorporated, rather than reporting both publishers as finished. If the requirement is to preserve both compatible edits, the example's one successful write is only part of the answer. Compare the offered application behavior with that requirement separately from the storage predicate. A conflict response identifies a boundary; it supplies no approval of either proposal. ## Scope surrounding physical storage connections separately If the wider infrastructure project also needs physical storage-network cabling, Leviathan's Structured Cabling & Fiber Installation service and related project inquiry can be used to discuss that work. Share a nonconfidential equipment outline, approved endpoints and routes, requested installation work, labels and required connection records. The service concerns agreed physical installation and handoff. Artifact publishing, cloud administration and application conflict handling remain with the appointed software and storage providers. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [A1 — AWS: Amazon S3 data consistency model](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel). Checked 2026-10-20. Strong reads and single-key atomicity explain the observation boundary; updates across keys do not form an atomic group. - [A2 — AWS: How to prevent object overwrites with conditional writes](https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html). Checked 2026-10-20. Distinguishes current-object ETag matching from existence checks and documents mismatch, conflicting-operation and deletion outcomes. The worked case isolates an existing key without deletion. - [A3 — AWS S3 API: PutObject — If-Match and If-None-Match](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html). Checked 2026-10-20. Defines the named replacement operation's predicates and 412 mismatch behavior. This article evaluates the behavior without prescribing requests or recovery automation. - [A4 — AWS S3 API: Object — ETag](https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html). Checked 2026-10-20. Limits ETag interpretation to contents rather than metadata and qualifies when the value represents an MD5 digest. - [R1 — RFC 9110: HTTP Semantics — entity tags, idempotency and preconditions](https://www.rfc-editor.org/rfc/rfc9110.html). Checked 2026-10-20. June 2022 sections 8.8.3, 9.2.2, 13 and 13.1.1 supply opaque-validator, repeated-effect and lost-update semantics. S3 documentation supplies the example's concrete result. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Agreed physical cabling, endpoint labels and connection records define the separate hardware-project inquiry. ## Related Leviathan resources - [Strong S3 reads and complete multi-object dataset releases](/articles/ai-dataset-s3-consistency-versus-complete-release) - [S3 ETags and checksum integrity evidence](/articles/ai-dataset-s3-etag-versus-checksum-integrity) - [Retry keys, operation scope and repeated effects](/articles/api-idempotency-key-scope-request-effects) - [Structured Cabling & Fiber Installation](/services/structured-cabling) - [Project inquiry for physical storage-network connections](/contact?service=structured-cabling&from=%2Farticles%2Fs3-conditional-write-current-etag-lost-update) ## Does the wider project need physical storage cabling? Share the equipment, approved endpoints and routes, requested cabling and required connection records to discuss physical scope and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/s3-conditional-write-current-etag-lost-update)