CAS-021: Ambiguous conditional-write outcomes are reported as definite ownership

[alsugiliazova]

✅ I checked the Altinity Stable Builds lifecycle table, and the Altinity Stable Build version I'm using is still supported.

Type of problem

Bug report — integrity. Split out of tracking issue #2031 (CAS-021, prev CAS-035). Static analysis of PR #2159 / cas-code-only-strip; not yet reproduced end-to-end.

Describe the situation

When a conditional object-store write (create-if-absent / If-Match overwrite) does not return a definite ACK, the CAS request controller guesses a definite outcome from a later GET/HEAD.

Two complementary lies:

1. Content equality is treated as proof that this attempt committed. After 412, 500, timeout, or a lost 200, putOverwriteControlled / putIfAbsentControlledMutable GET the key and, if got->bytes == bytes_s, return Committed with got->token — the current object's etag, which may belong to another writer.
2. A landed-then-timed-out write is reported as another writer's object. After the same ambiguity, conditionalCreateControlled / slotOccupy see that the key exists and return Occupied with unresolved_reason = NotUnresolved.

Content equality answers “is the durable value the value I intended?” It does not answer “did this client's conditional PUT succeed?” That second question is authorship. It is only recoverable from this PUT's 200+etag, or from a writer/attempt id embedded in the object. Blob freshness meta is generic {state, condemn_round, size} — no owner.

This issue:

• Erases compare-and-set exclusivity on mutable keys (casMeta / putMetaIfAbsent)
• Hands the loser the winner's etag, so a later If-Match can splice the CAS chain
• Lets GC treat a false Committed as “I confirmed the condemn marker,” which licenses deleteExact of the blob body
• Lets a lost ACK of our own ref-log append be classified as foreign occupancy and fault the mount as impossible interference

The same codebase already does the correct thing for the server-root owner anchor: claimOwnerOrThrow rereads the object and accepts only if server_uuid == our_uuid.

---

How to reproduce the behavior

Environment

• Version: CAS as in PR [experimental] CAS (Content-addressed storage) over shared object storage for antalya-26.6 #2159 (feature/antalya-26.6/CAS, audited on cas-code-only-strip at 842f2b37b8f)
• Build type: n/a (code-path finding; trigger is a lost ACK / 5xx / 412 on a conditional PUT)

Steps (logical)

The controller never distinguishes “PUT applied, ACK lost” from “PUT refused” from “PUT never applied.” Any of: dropped 200, HTTP 500/503, timeout after send, or a definite 412 followed by GET.

Direction A — false Committed (generic mutable key)

1. Two writers issue casMeta / putOverwriteControlled of identical bytes to one blob-meta key (GC condemn of {Condemned, round N, size S} is the realistic pair: two GC actors, or a retry).
2. Winner's If-Match succeeds. Loser's If-Match is 412, or either writer times out after the store applied the PUT.
3. Loser (or the timed-out winner) GETs, sees matching bytes, returns {Committed, got->token}.

Direction B — false Occupied (lost ACK of our own create)

1. Writer does putIfAbsent / slotOccupy / conditionalCreateControlled. Store applies it; ACK is lost.
2. Controller HEAD/GETs, key exists, returns Occupied and claims the outcome is not unresolved.

---

Expected behavior

An ambiguous conditional-write result stays Unresolved. Callers already have a wedge/retry for that (ref-log append). Do not return Committed. Do not return Occupied/Conflict. Do not adopt got->token as ours.

Ownership of a mutable key is only:

• the etag from this PUT's 200, or
• a writer-unique attempt id inside the payload (as claimOwnerOrThrow already checks server_uuid)

Byte equality of generic content is not authorship.

---

Actual behavior

False Committed + stolen token

CasRequestControl.cpp putOverwriteControlled — any non-Done PUT, including definite 412, falls into GET; equal bytes → Committed with the GET's token:

else if (got && got->bytes == bytes_s)
{
    ...
    return {CasOverwriteOutcome::Committed, got->token};
}

Same shape in putIfAbsentControlledMutable. putIfAbsentControlled uses resolveByExactGet, which also maps equal bytes → Committed.

False Occupied

conditionalCreateControlled: after a thrown/non-Done attempt, head(key).exists → {Occupied, {}} with no token and no unresolved reason.

slotOccupy: GET exists → Kind::Occupied, unresolved_reason = NotUnresolved, occupant_bytes possibly our own.

---

Root cause analysis

classifyConditionalWriteResult correctly maps 500 / timeout / lost 200 to Unresolved (only malformed / entity-too-large / access-denied are DefiniteFailure). The bug is the resolution ladder after that: a later GET/HEAD of a shared key is treated as the PUT's result.

Blob meta has no owner id:

struct BlobMeta {
    uint8_t version = 1;
    MetaState state = MetaState::Clean;  // clean | condemned
    uint64_t condemn_round = 0;
    uint64_t size = 0;
};

casMeta / putMetaIfAbsent feed that encoding into the controller. Two processes that want the same {Condemned, N, S} write identical bytes, so the equality branch fires even on a definite 412.

Consequence chain (GC)

Gc::writeCondemnedMeta treats outcome == Committed as “this process won the condemn CAS”:

if (writeCondemnedMeta(*store, ref, condemn_round, size))
    noteCondemnMarkerDurable(ref, token);

That in-process set is later trusted without re-reading meta:

if (condemnMarkerConfirmedInProcess(entry.ref, entry.token))
    return true;

The blob is graduated to delete_pending and deleteExact(blobKey, token) runs.

A part writer uses the same controller to move meta the other way (writeResurrectMetaClean: casMeta(..., Clean)). Both sides can take Committed from equality of generic {Clean,…} / {Condemned,…}. GC's local confirmation can then delete a body a writer has already re-admitted.

Consequence chain (Occupied → mount fault)

Wedge resolution classifies slotOccupy's Occupied payload. Equal bytes → Ours (accidentally OK for unique ref-log keys). Anything else, including a decode failure, is Foreign → lane Faulted, mount fenced, CORRUPTED_DATA “impossible foreign interference.”

Blob create maps Occupied to PreconditionFailed and adopts the object as a peer's live incarnation (PartWriteTxn::uploadFromSource), including when the occupant is our own lost-ACK write.

What is not this bug

Content-addressed blob keys (key = hash of bytes): “occupied at blobs/<hash>” means those bytes exist; adopting them does not claim exclusive create. The defect is using that reasoning on mutable slots (blob meta, mount/owner, ref-log occupy) whose payload does not name the writer.

---

Additional context

Anchors (CA/ = src/Disks/DiskObjectStorage/MetadataStorages/ContentAddressed/)

• CA/Backend/CasRequestControl.cpp:427-435, :498-506 — equality → Committed + stolen token
• CA/Backend/CasRequestControl.cpp:357-368, :543-562 — existence → Occupied
• CA/Backend/CasRequestControl.cpp:229-233 — resolveByExactGet same equality rule
• CA/Backend/CasObjectStorageBackend.cpp:109-124 — NoSuchKey mapped to PreconditionFailed
• CA/Pool/CasBlobMeta.cpp / Formats/CasBlobMetaFormat.h — generic meta, no owner
• CA/Gc/CasGc.cpp writeCondemnedMeta / noteCondemnMarkerDurable / deleteExact
• CA/Pool/CasPartWriteTxn.cpp writeResurrectMetaClean, uploadFromSource Occupied → adopt
• CA/Pool/CasRefLedger.cpp classifyRefLogOccupant, wedge Foreign → Faulted
• Contrast (correct): CA/Pool/CasServerRoot.cpp claimOwnerOrThrow compares server_uuid

Tracking

• CAS — consolidated static analysis audit findings (tracking) #2031 CAS-021 — resolution 🔴 still-present (carried from prev CAS-035); evidence now bidirectional
• Audit gist (2026-08-12): https://gist.github.com/alsugiliazova/6dce01834f93cdb7cdbb2fc70d1efc5f — NEW-FINDINGS.md CAS-021; reports/tier2.md tier2-4 / tier2-5

Suggested fix direction

Leave ambiguous results Unresolved. Do not promote GET/HEAD to Committed/Occupied. Do not return a GET etag as ours. If a protocol needs “I won this slot,” put a writer-unique attempt id in the payload and only treat a 200 of this PUT as Committed.

Update (2026-08-14) — narrowed after design review

The original report and the follow-up comment mixed different object types that the protocol treats differently on purpose. That overstated CAS-021. This update is the corrected scope.

Filimonov’s split is the right frame:

• Blob bodies have no owner. There are only edges in the graph (ref → manifest → blob). It does not matter who uploaded the bytes. Occupied at blobs/<hash> means those bytes exist; adopting them is the design, not a bug.
• Refs and manifests have exactly one writer per server_root_id, via the mount lease. The realistic race is this process against its own retry after a lost ACK, not two owners. Byte equality after GET on a lease-unique key (writer_epoch, seq / ManifestId) is “my attempt is durable.” Foreign is meant to be impossible and fail-closed.

The original “you must never infer authorship from content” is too wide here. Under a healthy mount lease, GET-after-ambiguity on those unique keys is a self-retry resolver, not an ownership oracle.

GC is not that writer. It does not take the mount lease. It takes a separate lease on gc/state (one leader per pool). That is a second actor, but it does not make blob bodies owned.

---

What the original report got wrong

Claim in the original / comment	Reality
Blob create Occupied → adopt is an integrity failure	Not a bug. Hash key, no owner.
Ref-log / manifest / snapshot Committed via byte equality after lost ACK	By design under the mount lease (self-retry of a unique id).
Wedge Occupied + equal bytes → Ours	By design (same attempt). Foreign is the invariant alarm if the lease held.
Two writers of opposite blob-meta (Clean vs Condemned) both “win” via equality	Does not happen. Different payloads → Conflict → retry.
Stolen GET etag splices the CAS chain today	Loaded gun, not a current firing path. GC and resurrect check .outcome only and discard the token.
The six controller exits are six extra bugs	One API. Most callers are consistent with the design split above.

The long consumer map in the first comment is still a useful inventory of call sites. It is not a list of distinct integrity holes.

---

What is still real (narrower)

1. The controller API names the wrong thing.

After a PUT that is not a clean Done, putOverwriteControlled / putIfAbsentControlledMutable / resolveByExactGet return Committed + the GET etag when bytes match — including on a definite 412. conditionalCreateControlled / slotOccupy return Occupied with unresolved_reason = NotUnresolved when the key exists.

classifyConditionalWriteResult already maps timeout / 500 / lost 200 to Unresolved. The GET/HEAD ladder then promotes that to a definite win/loss. For blob bodies and lease-unique refs that promotion is often the intended end state (“bytes I wanted are there” / “my unique slot is durable”). Returning Committed still means “this attempt won,” which is a lie when the PUT was 412 or never ACKed. That is API hygiene / a footgun, not proof of today’s data loss.

2. Blob meta is not a blob.

BlobMeta is {state, condemn_round, size} — a mutable flag between GC and writers, not content-addressed data and not covered by the mount lease.

• Two GCs writing the same {Condemned, round N, size}: equality → both see Committed. That is the same fact as writeCondemnedMeta’s if already Condemned return true. Idempotent. Who wrote the marker does not matter if the next delete re-reads meta.
• GC vs INSERT write opposite payloads → Conflict, not false Committed.
• What can go stale: in-process condemn_markers_confirmed is trusted without a meta re-read (confirm_condemned_marker). That is a GC confirmation shortcut, not “blobs have owners.”

3. Call sites that ignore the CAS result (survive a controller-only fix).

• observeAndAdmit discards putMetaIfAbsent(Clean). If GC already put Condemned, the writer can still adopt. That is “ignore the outcome,” adjacent to CAS — consolidated static analysis audit findings (tracking) #2031 CAS-002, not content-as-authorship.
• claimMount: putIfAbsent / putOverwrite != Done → LiveDoubleStart with no GET. Lost ACK of our mint can refuse the disk. Liveness, not blob ownership. When the slot already exists, claimMount does compare server_uuid (correct).

4. Not this issue

• CAS-003 (CAS — consolidated static analysis audit findings (tracking) #2031): two GC leaders overlapping destructive phases (lease has no TTL; heartbeat casPut result discarded; blob deleteExact not revalidated). That is the serious “GC isn’t one” question. Separate from CAS-021.
• CAS-011, CAS-068: different mechanisms.
• CAS: SYSTEM CAS GC RUN on a follower silently does nothing (acquired_lease=0) #2211: SYSTEM CAS GC RUN on a follower silently no-ops. Operator UX, not this protocol.

---

Expected behavior (revised)

Do not treat blob-body Occupied or lease-unique self-retry as bugs.

Do not steal a live GC lease to “fix” this (see CAS-003).

Still worth doing:

• Stop returning Committed on a definite 412 just because GET bytes match; that is “desired state present,” not “this attempt won.” Keep a distinct outcome or stay Unresolved and let the caller re-read.
• Do not return a GET etag as if it were this PUT’s token unless the PUT returned Done.
• observeAndAdmit must honor putMetaIfAbsent / casMeta (Conflict / condemned).
• Optionally: claimMount should GET and compare server_uuid on non-Done, not assume another live server.

A stress test that only checks “who uploaded the blob” will confirm Filimonov and miss the remainder. The interesting test is GC vs concurrent INSERT on the same hash (condemn vs adopt/resurrect), with injected 412/timeout on the meta PUT — and, separately, CAS-003 (two GC actors).

Not reproduced end-to-end. Static / logical only.

[alsugiliazova]

Follow-up: complete map of where ownership is misclassified and what each consumer then does. Same root cause as the issue body (ambiguous conditional PUT promoted to a definite win/loss). Not separate bugs — a controller-only fix that leaves results Unresolved and never returns a GET etag as ours addresses these, except the two call sites that bypass the controller (called out at the end).

CA/ = src/Disks/DiskObjectStorage/MetadataStorages/ContentAddressed/.

---

Where the lie is

After a PUT that is not a clean Done, these exits GET/HEAD and invent a definite outcome.

Site	Invented outcome	Rule
CA/Backend/CasRequestControl.cpp resolveByExactGet :229-233	Committed + GET etag	got->bytes == expected
putIfAbsentControlled :290-312	same, via resolveByExactGet	412, 500, timeout, lost 200 all go here
putOverwriteControlled :424-438	Committed + GET etag, or Conflict	equal bytes → we won; different → they won. Even on definite 412
putIfAbsentControlledMutable :495-509	same as overwrite	equal bytes → we won
conditionalCreateControlled :357-368	Occupied, no token	HEAD exists. No byte compare
slotOccupy :557-562	Occupied + occupant bytes/token, unresolved_reason = NotUnresolved	GET exists. No byte compare

Backend feeder: CA/Backend/CasObjectStorageBackend.cpp:117-120 finalizeConditionalWrite maps S3 NoSuchKey to PreconditionFailed. A missing key becomes “someone else owns this.”

Second authorship test (not a 200 of this PUT): CA/Pool/CasRefLedger.cpp classifyRefLogOccupant :120-128 — occupant_bytes == expected_bytes → Ours, else decode → epoch seal or Foreign.

Content equality answers “is the durable value what I intended?” It does not answer “did this client's conditional PUT succeed?” Authorship is only the etag from this PUT's 200, or a writer/attempt id inside the object. Generic payloads (blob meta {state, condemn_round, size}) have no owner.

---

Consumers and side effects

1. Blob meta — casMeta / putMetaIfAbsent (generic, no owner)

CA/Pool/CasBlobMeta.cpp → putOverwriteControlled / putIfAbsentControlledMutable. Two writers of {Condemned, round N, size S} or {Clean, 0, size} write identical bytes, so the equality branch fires even on a definite 412.

GC CA/Gc/CasGc.cpp writeCondemnedMeta :89-98 → scheduleCondemnMarkerWrite :357-358 → noteCondemnMarkerDurable.

False report	Side effect
Committed	This process records (blob, body-token) as a confirmed condemn marker. Later confirm_condemned_marker :1352-1353 trusts that in-process set without re-reading meta. Blob is graduated to delete_pending. runRegularRound :613 does deleteExact(blobKey, token) then deleteConfirmedMeta. Blob body is deleted because this node believes it sealed the condemn. If a writer has casMeta'd the same key back to Clean and admitted the blob into a part, that part names a blob GC is about to remove.
Conflict / Unresolved	Marker not noted; blob carried; next round retries. Conservative.

Writer CA/Pool/CasPartWriteTxn.cpp writeResurrectMetaClean / writeFreshMetaClean :361-384.

False report	Side effect
Committed	Loop exits; blob treated as live Clean; BlobDepRecord goes into the part manifest; INSERT/merge succeeds.
Conflict / Unresolved	Reload meta, retry up to 8 times, then throwCasWriteRetryLater. No silent admit.

observeAndAdmit :287-304 — putMetaIfAbsent(Clean) return value discarded. Any controller outcome is ignored. The blob is adopted as a live dependency even if the Clean marker never landed, conflicted, or was a false Committed of someone else's Clean. A part can name a blob with missing/Condemned meta; GC is free to retire it. This caller bug survives a controller-only fix unless the result is checked.

Stolen GET etag: GC/writer today only test .outcome. The controller still hands got->token back as ours; any later If-Match with it splices the CAS chain.

---

2. Blob body create — conditionalCreateControlled → uploadFromSource

CasPartWriteTxn.cpp:406-449. False Occupied (our PUT landed, ACK lost, HEAD exists) → PreconditionFailed, then:

• HEAD exists, meta not Condemned → observeAndAdmit (treat as a peer's live blob).
• HEAD exists, meta Condemned → resurrect (overwrite body, then writeResurrectMetaClean).
• HEAD gone → retry create, or HeadMissAdopted.

Side effects: we never take the “I created this” path (no PUT token, BlobReuseAdopt instead of BlobPut). If GC condemned in the window: ABORTED / resurrect instead of acknowledging our own create. Adoption uses the HEAD token, not the PUT etag we never got. For a hash key adopting the same bytes is not exclusive-create; it is still a false “not mine.” Honest Unresolved here is throwCasWriteRetryLater (re-upload).

---

3. Manifest create — putIfAbsentControlled → stageManifest

CasPartWriteTxn.cpp:550-573. Key unique per ManifestId.

False report	Side effect
Committed via resolveByExactGet	Keep GET etag as manifest_token, emit ManifestPut, push id into staged_manifests, later precommitAdd publishes a ref to it. Lost ACK of our bytes: we did create it (OK-ish). Identical encoding from another txn: both believe they staged the same identity. Different bytes: resolveByExactGet throws CORRUPTED_DATA — part write dies (fail closed).
Unresolved	Retry-later with a fresh ManifestId. If the first PUT actually landed, that body is orphaned (leak).

---

4. Ref-log append — putIfAbsentControlled → commitRefChunk

CasRefLedger.cpp:2455-2720. Key unique (namespace, writer_epoch, seq).

False report	Side effect
Committed (lost ACK, GET bytes match)	Publish checkpoint frontier, install the txn into in-memory ref state, ack the SQL mutation (committed_id, done = true), maybe snapshot. Callers think the append is durable and exclusive. Same bytes at a unique key is usually our retry (what we wanted). A peer with the same epoch writing the same encoding: both mounts install the same history.
CORRUPTED_DATA from resolveByExactGet (different bytes)	Classify occupant (below).
Honest Unresolved (GET failed / key absent)	Lane Wedged; SQL error “uncertain”; retry must hit the same key via slotOccupy. Correct protocol — skipped whenever the controller already lied Committed.

On occupant classify after different bytes / unreadable GET:

Occupant	Side effect
SuccessorSeal	Lane Closed. This epoch's appends refused until a new epoch.
Foreign / unreadable	reportImpossibleInterference (CasPool.cpp:972-990): ForeignInterference event, tripMountLost, remount. Disk refuses all durable writes (mayMutate() false) until remount.
Unreadable GET	Lane Faulted without classifying.

---

5. Wedge resolution — slotOccupy

CasRefLedger.cpp:1639-1849. False Occupied after unknown PUT (including our lost ACK):

Occupant	Side effect
Ours (bytes equal)	Treated as durable. Publish frontier, install txn, unwedge, ack SQL. Same as false Committed in (4).
SuccessorSeal	Lane Closed. This epoch's appends dead.
Foreign (including decode failure)	Lane Faulted, mount fenced, remount. Worst when GET is not an exact byte match (partial read, replica, different encoding of “our” txn): we declare impossible interference and take the disk down.
GET failed	Stay Wedged. Honest.

---

6. Recovery epoch-seal — slotOccupy (no Ours check)

CasRefLedger.cpp:772-822.

False report	Side effect
Occupied	Decode occupant_bytes, apply_one that txn as recovered history, publish recovered frontier, advance epoch/seq. Our lost-ACK seal: applying it is the right history. A straggler's different txn at that slot: we install their seal/append as this table's log, then checkpoint it. There is no Ours check on this path. Decode throw: table stays unrecovered (fail closed).
Created	Apply our seal. Fine.
Unresolved	throwCasWriteRetryLater; table not exposed. Honest.

---

7. Snapshot put — putIfAbsentControlled

CasRefLedger.cpp:3009-3016 tryPublishSnapshotAndAdvanceCheckpointOnceOnRuntime.

False report	Side effect
Committed	Believe the snapshot object is ours, then publishCkptContribution advances _ckpt to that snapshot id. GC may then delete older snapshots under that checkpoint. If we advanced on a peer's snapshot we did not write, in-memory tail can disagree with the durable snapshot, or we allow deletion of a snapshot we still need.
Unresolved	Backoff, retry later. Honest.

---

8. Decommission owner tombstone — putOverwriteControlled

CA/Tools/CasDecommission.cpp:338-350. Owner object does contain server_uuid + retired_at_ms.

False report	Side effect
Committed (GET bytes == our tombstone)	report.slot_removed = true. Operator is told the member is gone.
Conflict (GET is a live owner or a different tombstone)	Warning, slot kept. If this was our landed tombstone and GET hit a stale/wrong object: we fail to mark removed, or we abort a delete that already happened.
Unresolved	Warning, rerun. Honest.

---

Bypasses the controller (same class, would survive a controller-only fix)

claimMount (CA/Pool/CasServerRoot.cpp:310-313, :336-337, :349-350): putIfAbsent / putOverwrite != Done → LiveDoubleStart. No GET, no uuid compare on that failure. Lost ACK of our mint/refresh is reported as another live server. Side effect: disk refuses to mount (CasPool.cpp:453, :713). (When the slot already exists, claimMount does compare server_uuid — that part is correct.)

observeAndAdmit discarding putMetaIfAbsent — see (1). Even a correct Conflict/Unresolved is ignored.

Related, already tracked elsewhere — do not split out:

• CAS-011 (CAS — consolidated static analysis audit findings (tracking) #2031): CasPlainObjects::casPutObject — non-Done is not success, but the next loop putOverwrites with a fresh HEAD token and our bytes (namespace files / mountpoint objects clobbered after an ambiguous create).
• CAS-068 (CAS — consolidated static analysis audit findings (tracking) #2031): putIfAbsentControlled swallows deterministic local failures as Unresolved (opposite direction).
• publishCkpt catch path (CasRefCkpt.cpp:229-230): after ambiguous casPut, if merge(current, ours) == current → Published. That is “the merge already contains our contribution,” not “I won the CAS.” Safer; still not a 200.

---

Side-effect summary

False report	Where	What the process then does
Committed on generic meta	GC condemn	Confirm marker → delete blob body
Committed on generic meta	Writer resurrect/fresh	Admit blob into part; INSERT succeeds
Committed (ignored)	observeAndAdmit	Adopt blob even if Clean meta did not land
Occupied on blob create	uploadFromSource	Adopt or resurrect as if peer created it
Committed on manifest	stageManifest	Name that manifest in the part; use GET etag as ours
Committed on ref-log	commitRefChunk	Checkpoint + install + ack the write to SQL
Occupied + Ours	wedge	Same as ref-log Committed (unwedge)
Occupied + Foreign	wedge / append	Fence the mount, remount, table writes fail
Occupied + SuccessorSeal	wedge / append	Close the writer epoch
Occupied (no Ours check)	recovery seal	Install occupant txn as recovered history + checkpoint
Committed on snapshot	snapshot publish	Advance _ckpt; enables GC of older snapshots
Committed on owner tombstone	decommission	Report member removed
Conflict / LiveDoubleStart on mount PUT	claimMount	Disk will not start
NoSuchKey → 412	any conditional PUT	Feeds all of the above as a definite loss

---

Not this bug (correct pattern already in-tree)

Re-read the object and check an id in the payload:

• claimOwnerOrThrow — server_uuid == our_uuid
• claimMount when the slot already exists — existing.server_uuid != our_uuid
• PoolMeta::createOrValidate after create Conflict — admit the winner's decoded meta, do not claim we minted pool_id

Content-addressed blob keys (key = hash of bytes): Occupied means those bytes exist. Adopting them is not exclusive-create. Using that same reasoning on blob meta, ref-log occupy, mount, owner, and snapshots is the bug.

A controller fix that stays Unresolved and never returns a GET etag as ours covers the table above except claimMount and observeAndAdmit's discarded result — those two must be changed at the call site.