Proposal: conditional DELETE (If-Match) on DeleteObject for general-purpose buckets

[tomsanbear]

AWS shipped conditional DELETE for S3 general-purpose buckets on 2025-09-16 — clients can send If-Match: <etag> (or *) on DeleteObject, and the service returns 412 PreconditionFailed on mismatch or 404 NoSuchKey when the object's absent and If-Match was sent.

RustFS already parses the If-Match header on DELETE (via fill_conditional_writes_opts_from_header, landed yesterday in #2592) but doesn't honor it in delete_object, so clients that send it silently lose the precondition check. There's not much of a client-side workaround — the alternative is HEAD-then-DELETE, which costs an extra GET-class request per op (DELETE is free on AWS).

AWS refs: conditional-deletes guide, launch announcement.

Proposed behavior

Honor If-Match on DeleteObject, matching the AWS status-code matrix:

State	HTTP	<Code>
Object present, ETag matches	204	—
Object present, ETag mismatch	412	PreconditionFailed
Object absent + If-Match sent (any value, incl. *)	404	NoSuchKey
Object absent + If-Match absent	204 (idempotent)	—
If-Match: * + live object	204	—
If-Match: * + current version is delete marker	412	PreconditionFailed

Verified against 83bac394 (current main):

• Headers are already parsed — rustfs/src/storage/options.rs::del_opts stores If-Match into opts.http_preconditions.
• Error wire mapping is correct — StorageError::PreconditionFailed → 412, StorageError::ObjectNotFound → 404 in rustfs/src/error.rs.
• The only gap is SetDisks::delete_object at crates/ecstore/src/set_disk.rs:1725 — it doesn't read opts.http_preconditions.

Proposed shape: add a sibling helper check_delete_precondition in crates/ecstore/src/set_disk/write.rs, mirroring check_write_precondition (async, no_lock = true, returns Option<StorageError>). Wire it at a single call site in delete_object, gated on opts.http_preconditions.is_some(). Delete-marker semantics invert vs. the PUT helper — on DELETE with If-Match, a delete-marker current version should return PreconditionFailed, because the current-version view is "not there."

A note on scope

Sticking to what AWS ships for general-purpose buckets, so leaving these out:

• If-None-Match / If-Modified-Since / If-Unmodified-Since on DELETE — AWS doesn't accept them here.
• x-amz-if-match-last-modified-time / x-amz-if-match-size — directory-bucket-only.
• Per-object If-Match in batch DeleteObjects — AWS's batch XML body doesn't accept it.

Alternatives I considered

• Parameterize check_write_precondition with a flag. Rejected because the delete-marker branch inverts and the PUT helper's should_prevent_write encodes PUT-specific semantics — a flag would fork the body enough that a sibling is cleaner. The sibling also mirrors the existing PUT helper pattern.
• Leave it as-is. Silently ignoring the header is probably the worst option — worse than either rejecting or honoring it, and leaves clients worse off in a way they can't easily detect.

Open questions

1. Scope — OK to implement? Didn't see this in 📝 To-Do Task Pool & Help Wanted #158 or any existing issue/PR.
2. Versioned buckets with versionId + If-Match — AWS docs explicitly scope conditional DELETE to the current version and are silent on the combination. Current plan: check against the named version's ETag (inherit whatever get_object_info version resolution returns). Any preference, or should I just flag it in the PR as "our interpretation"?
3. Non-goals — are the scope boundaries above right, or should any of them move in-scope?

Prior work I looked at

• feat: enhance error handling and add precondition checks for object o… #1008 added the precondition-check infrastructure back in December 2025 and explicitly flagged DeleteObject → PreconditionFailed (412) as a motivation in the PR body — but only wired the helper into the read path. This PR would finish that work.
• test(e2e_test): add automated cluster environment for conditional PUT race test #1673 added cluster race-test scaffolding for conditional PUT, which I'd mirror for a concurrent-delete race test.
• fix(s3): ignore empty conditional ETag headers #2592 landed the current header-parsing call in del_opts (yesterday).

Verification plan

No unit tests exist in set_disk/write.rs today so I'm deferring unit coverage (helper is a straightforward composition of get_object_info + etag comparison — happy to add scaffolding if you'd rather). E2e coverage in a new conditional_deletes.rs mirroring conditional_writes.rs, make pre-commit gate before push.

---

Happy to hold off on the PR if anyone wants to weigh in first, or redirect me if someone else has already tackled this or you'd prefer a different shape. Let me know how you'd like me to proceed.