Existing documentation URL(s)
https://developers.cloudflare.com/r2/api/s3/api
https://developers.cloudflare.com/r2/reference/consistency/
What changes are you suggesting?
We are evaluating Cloudflare R2's S3-compatible API for a create-once control record and found two storage semantics that do not appear to be explicitly documented.
- Concurrent conditional PutObject
For a previously absent key, if two or more clients concurrently issue PutObject with If-None-Match: *, is the precondition evaluated atomically against committed bucket state such that at most one request can return HTTP success?
Specifically, can two concurrent If-None-Match: * PutObject requests to the same previously absent key ever both return a 2xx success?
If this guarantee exists, please clarify it in the R2 documentation, including the expected result for competing requests.
- Negative read following an ambiguous PutObject
Suppose a client sends a PutObject request and loses its connection before receiving the response, so the client cannot determine whether the write committed.
If a subsequent strongly consistent HeadObject or GetObject returns NoSuchKey, is that absence final with respect to the earlier request?
In other words, can the earlier in-flight request still subsequently commit after the negative read has returned?
If R2 defines this ordering/finality guarantee, please document it explicitly.
These clarifications would help users who rely on conditional object creation for create-once records, distributed coordination, and fail-closed control mechanisms.
This question concerns the current R2 S3-compatible API only and requires no account-specific information.
Additional information
No response
Existing documentation URL(s)
https://developers.cloudflare.com/r2/api/s3/api
https://developers.cloudflare.com/r2/reference/consistency/
What changes are you suggesting?
We are evaluating Cloudflare R2's S3-compatible API for a create-once control record and found two storage semantics that do not appear to be explicitly documented.
For a previously absent key, if two or more clients concurrently issue PutObject with If-None-Match: *, is the precondition evaluated atomically against committed bucket state such that at most one request can return HTTP success?
Specifically, can two concurrent If-None-Match: * PutObject requests to the same previously absent key ever both return a 2xx success?
If this guarantee exists, please clarify it in the R2 documentation, including the expected result for competing requests.
Suppose a client sends a PutObject request and loses its connection before receiving the response, so the client cannot determine whether the write committed.
If a subsequent strongly consistent HeadObject or GetObject returns NoSuchKey, is that absence final with respect to the earlier request?
In other words, can the earlier in-flight request still subsequently commit after the negative read has returned?
If R2 defines this ordering/finality guarantee, please document it explicitly.
These clarifications would help users who rely on conditional object creation for create-once records, distributed coordination, and fail-closed control mechanisms.
This question concerns the current R2 S3-compatible API only and requires no account-specific information.
Additional information
No response