Fix name of UNSAFELY_INCOMPATIBLE_WITH_S3_CONDITIONAL_WRITES #138406
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
In elastic#137185 we introduced a new S3 repository setting called `unsafely_incompatible_with_s3_conditional_writes` but named the code symbol `UNSAFELY_INCOMPATIBLE_WITH_S3_WRITES` omitting the "conditional" bit. That makes the dependent code confusing to read, so this commit fixes the symbol name.
DaveCTurner added >non-issue :Distributed Coordination/Snapshot/Restore 
elasticsearchmachine added v9.3.0 Team:Distributed Coordination 
Collaborator
| Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
…DITIONAL_WRITES-rename
DaveCTurner deleted the 2025/11/21/UNSAFELY_INCOMPATIBLE_WITH_S3_CONDITIONAL_WRITES-rename branch ncordon pushed a commit to ncordon/elasticsearch that referenced this pull request Nov 26, 2025
…ic#138406) In elastic#137185 we introduced a new S3 repository setting called `unsafely_incompatible_with_s3_conditional_writes` but named the code symbol `UNSAFELY_INCOMPATIBLE_WITH_S3_WRITES` omitting the "conditional" bit. That makes the dependent code confusing to read, so this commit fixes the symbol name.
DaveCTurner added a commit to DaveCTurner/elasticsearch that referenced this pull request Nov 27, 2025
As of elastic#133030 Elasticsearch uses S3's support for conditional writes to protect against repository corruption. It is possible that some other storage system may claim to be fully S3-compatible despite rejecting such requests. This commit adds a repository setting that allows to make all writes unconditional, unsafely disabling the corruption protection, but allowing users some time to work with their storage supplier to address the incompatibility. Backport of elastic#137185 and elastic#138406 to 9.2
DaveCTurner added a commit that referenced this pull request Nov 28, 2025
As of #133030 Elasticsearch uses S3's support for conditional writes to protect against repository corruption. It is possible that some other storage system may claim to be fully S3-compatible despite rejecting such requests. This commit adds a repository setting that allows to make all writes unconditional, unsafely disabling the corruption protection, but allowing users some time to work with their storage supplier to address the incompatibility. Backport of #137185 and #138406 to 9.2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
In #137185 we introduced a new S3 repository setting called
unsafely_incompatible_with_s3_conditional_writesbut named the codesymbol
UNSAFELY_INCOMPATIBLE_WITH_S3_WRITESomitting the "conditional"bit. That makes the dependent code confusing to read, so this commit
fixes the symbol name.