Fix name of UNSAFELY_INCOMPATIBLE_WITH_S3_CONDITIONAL_WRITES
#138406
Merged
+7
−7
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.