Multi-Writer Prevention : Conditional Upload Flow & Logic #18522
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.
Related Issues/RFCs:
Problem Statement
OpenSearch clusters using remote-backed storage are susceptible to data inconsistencies when multiple primary shards concurrently attempt to upload segment metadata—particularly during network partitions or primary failovers. A stale (previously active) primary might overwrite metadata written by the newly promoted one. This risk undermines cluster safety and complicates automation in recovery flows.
Current multi-writer detection mechanisms are not robust enough to handle this reliably.
Solution Overview
This PR introduces ETag-based conditional writes to the remote segment metadata upload process. ETags (version identifiers from cloud storage systems like S3, GCS, or Azure) allow OpenSearch to safely coordinate access to shared resources. This mechanism ensures only the correct primary shard can write metadata, while stale primaries self-detect and fence themselves.
Key enhancements:
ETag-Based Conditional Writes:
Primary shards attach the known ETag to each metadata upload using the
If-Match
condition. If the ETag doesn't match the current version in the remote store, the write is rejected (HTTP 412 Precondition Failed).Fixed Metadata Filename:
To enable ETag-based coordination, segment metadata is now always written to a fixed filename (e.g.,
"segment_metadata"
) instead of legacy dynamic filenames.Stale Primary Self-Fencing:
failShard()
operation, fencing off the stale node.ETag Lifecycle Managed at Shard Level:
IndexShard
now caches the ETag for its segment metadata file and updates it based on the success/failure of remote operations.This design shifts writer validation from OpenSearch into the remote store’s atomic operations—improving correctness and simplifying state coordination.
Key Implementation Details
IndexShard
Introduces a
MetadataETagCache
per shard to hold the latest known ETag.Provides methods:
getMetadataETag()
updateMetadataETag()
clearMetadataETag()
On primary promotion, invokes
initiateNonConditionalRemoteMetadataUpload()
:RemoteStoreRefreshListener
During each metadata upload:
uploadMetadata(...)
with the ETag and a structuredActionListener
.On success: Updates shard’s cached ETag.
On
Precondition Failed
: Treats this as a stale primary detection, clears ETag, and callsfailShard()
for fencing.Logs other failures without failing the shard.
RemoteSegmentStoreDirectory
Accepts a
versionIdentifier
(ETag) and enhancedActionListener
.Constructs
ConditionalWriteOptions
based on the ETag:ifMatch
Always uses
"segment_metadata"
as the remote filename.RemoteDirectory
&BlobStore
copyFrom()
method now takesConditionalWriteOptions
.blobContainer.writeBlobConditionally(...)
for storage-provider-specific handling.Testing
Unit tests in
RemoteSegmentStoreDirectoryTests
have been expanded to verify:Related Issues
Implements part of RFC #17763
Parent Meta Issue: [META] Implement Conditional APIs for Multi-Writer Detection
Supersedes Introduce Interface changes to Support atomic conditional-writes #18065
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.
Visualizing the Changes
Sequence Diagram: Stale Primary Self-Fencing Mechanism

Demonstrates how an outdated ETag causes a 412 failure, triggering the stale primary’s self-initiated
failShard()
.Architecture: Core Components for Conditional Metadata Upload

Shows interaction flow between
IndexShard
,RemoteStoreRefreshListener
,RemoteSegmentStoreDirectory
,RemoteDirectory
, andBlobStore
, including ETag usage.Flowchart: New Primary’s Metadata Ownership Claim

Shows how a new primary clears its ETag cache, performs a non-conditional upload, and updates its local ETag before assuming control.