Add skeleton structure for WritableWarm Directories and IndexInputs

[GeekGlider]

Description

Adds the skeleton structure for WritableWarm directories, index inputs, and supporting components directly in the server core (server/src/main/java/org/opensearch/storage/). This PR lays the groundwork for tiered storage functionality by introducing the package structure and minimal class definitions for:

• Directory layer: TieredDirectory, TieredDirectoryFactory, OSBlockHotDirectory, OSBlockHotDirectoryFactory — skeleton classes for tiered storage directory implementations.
• Index input layer: BlockIndexInput, BlockFetchRequest, SwitchableIndexInput, SwitchableIndexInputWrapper, CachedSwitchableIndexInput, OnDemandPrefetchBlockSnapshotIndexInput — skeleton classes for block-based and switchable index input implementations.
• Common utilities: TieringUtils, TieringServiceValidator, TieringRejectionException, BlockTransferManager — shared utilities and validation logic.
• Prefetch: StoredFieldsPrefetch, TieredStoragePrefetchSettings — skeleton for stored fields prefetch support.

All classes are skeleton implementations with Javadoc, constants, and setting definitions only. No behavioral logic is included — implementation will follow in subsequent PRs. The @ExperimentalApi annotation is applied where appropriate.

Related Issues

Part of the tiered-storage open source plan.

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

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.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 8e579c0)

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 Multiple PR themes Sub-PR theme: Tiered Storage Directory skeleton classes Relevant files: server/src/main/java/org/opensearch/storage/directory/TieredDirectory.java server/src/main/java/org/opensearch/storage/directory/TieredDirectoryFactory.java server/src/main/java/org/opensearch/storage/directory/package-info.java Sub-PR theme: Tiered Storage IndexInput skeleton classes Relevant files: server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java server/src/main/java/org/opensearch/storage/indexinput/BlockIndexInput.java server/src/main/java/org/opensearch/storage/indexinput/CachedSwitchableIndexInput.java server/src/main/java/org/opensearch/storage/indexinput/OnDemandPrefetchBlockSnapshotIndexInput.java server/src/main/java/org/opensearch/storage/indexinput/SwitchableIndexInput.java server/src/main/java/org/opensearch/storage/indexinput/SwitchableIndexInputWrapper.java server/src/main/java/org/opensearch/storage/indexinput/package-info.java

⚡ Recommended focus areas for review Type Mismatch The outer class BlockFetchRequest declares directory as Directory (Lucene abstract type), but the inner Builder class declares it as FSDirectory. The private constructor assigns builder.directory (FSDirectory) to this.directory (Directory), which works via upcasting, but the getDirectory() method returns Directory. This inconsistency may cause issues for callers expecting FSDirectory and could lead to ClassCastException if the returned Directory is cast back to FSDirectory elsewhere. private final Directory directory; private final String fileName; private final String blockFileName; private final long blockStart; private final long blockSize; private final Path filePath; private BlockFetchRequest(Builder builder) { this.fileName = builder.fileName; this.blockFileName = builder.blockFileName; this.filePath = builder.directory.getDirectory().resolve(blockFileName); this.directory = builder.directory; this.blockSize = builder.blockSize; this.blockStart = builder.blockStart; } /** * Creates a new Builder. * @return a new Builder */ public static Builder builder() { return new Builder(); } /** * Returns the file path. * @return the file path */ public Path getFilePath() { return filePath; } /** * Returns the directory. * @return the directory */ public Directory getDirectory() { return directory; Null Fields The placeholder constructor sets fileName, fileSize, directory, and context to null/0. Since these are protected final fields, subclasses cannot override them. If any code path accidentally invokes methods on this skeleton before the real constructor is added, it will silently operate on null values rather than throwing a clear error, making debugging harder. BlockIndexInput(AbstractBlockIndexInput.Builder<?> builder) { super(builder); this.fileName = null; this.fileSize = 0; this.directory = null; this.context = null; } Null ConcurrentMap The clones field is initialized to null in the placeholder constructor. Since clones is typed as ConcurrentMap, any future code that iterates over clones (e.g., during switchToRemote or close) without a null check will throw a NullPointerException. Consider initializing it to an empty ConcurrentHashMap even in the placeholder. this.clones = null; Missing Validation The build() method in the Builder performs no validation (e.g., null checks for directory, fileName, blockFileName, or non-negative blockSize/blockStart). The constructor also calls builder.directory.getDirectory().resolve(blockFileName) which will throw a NullPointerException if directory or blockFileName is null. Input validation should be added before the implementation PR. public BlockFetchRequest build() { return new BlockFetchRequest(this); }

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to 8e579c0

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Add null validation for required builder fields The constructor accesses builder.directory.getDirectory() without a null check. If directory is not set on the builder before calling build(), this will throw a NullPointerException. Add validation in the build() method or constructor to ensure required fields like directory and blockFileName are non-null before use. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [32-39] private BlockFetchRequest(Builder builder) { + if (builder.directory == null) { + throw new IllegalStateException("directory must be set"); + } + if (builder.blockFileName == null) { + throw new IllegalStateException("blockFileName must be set"); + } this.fileName = builder.fileName; this.blockFileName = builder.blockFileName; this.filePath = builder.directory.getDirectory().resolve(blockFileName); this.directory = builder.directory; this.blockSize = builder.blockSize; this.blockStart = builder.blockStart; } Suggestion importance[1-10]: 5 __ Why: The suggestion is valid - accessing builder.directory.getDirectory() without null checks could cause NPEs. However, this is a scaffold/placeholder PR where full implementation is deferred, so the impact is limited for now.	Low
General	Return concrete FSDirectory type from getter The getDirectory() method returns the field typed as Directory, but the Builder stores it as FSDirectory. The filePath computation also relies on FSDirectory.getDirectory(). Returning the more general Directory type loses the FSDirectory-specific API. Consider returning FSDirectory from getDirectory() to preserve type information and avoid unsafe casts by callers. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [61-63] -public Directory getDirectory() { - return directory; +public FSDirectory getDirectory() { + return (FSDirectory) directory; } Suggestion importance[1-10]: 4 __ Why: The suggestion has merit since the field is stored as FSDirectory in the builder but exposed as Directory, losing type information. However, the improved_code uses an unsafe cast (FSDirectory) directory rather than changing the field type, which is not ideal. The impact is moderate as callers needing FSDirectory-specific methods would need to cast anyway.	Low
	Initialize clones map to avoid null dereference The clones field is initialized to null in the placeholder constructor but is declared as final. Any future code that attempts to use clones (e.g., clones.put(...)) without a null check will throw a NullPointerException. Consider initializing it to a new ConcurrentHashMap even in the placeholder constructor to avoid accidental NPEs during development or testing. server/src/main/java/org/opensearch/storage/indexinput/SwitchableIndexInput.java [64-66] private final ConcurrentMap<SwitchableIndexInput, Boolean> clones; // TieredStoragePrefetchSettings supplier will be added in the implementation PR private final ThreadPool threadPool; +// Placeholder constructor. Real constructors will be added in the implementation PR. +SwitchableIndexInput(String resourceDescription) { + super(resourceDescription); + this.fileCache = null; + this.fullFilePath = null; + this.switchableFilePath = null; + this.fileName = null; + this.fileLength = 0; + this.offset = 0; + this.localDirectory = null; + this.remoteDirectory = null; + this.transferManager = null; + this.isClone = false; + this.clones = new java.util.concurrent.ConcurrentHashMap<>(); + this.threadPool = null; +} + Suggestion importance[1-10]: 3 __ Why: The improved_code goes beyond the existing_code snippet by also modifying the constructor body, making it inconsistent with the stated scope. Additionally, since all methods throw UnsupportedOperationException, initializing clones to a non-null map in the placeholder constructor has minimal practical impact.	Low

---

Previous suggestions

Suggestions up to commit 8b52669

Category	Suggestion	Impact
Possible issue	Add null check before dereferencing builder field The constructor accesses builder.directory.getDirectory() without a null check. If directory is not set on the builder before build() is called, this will throw a NullPointerException. Add a null validation in the build() method or in the constructor before dereferencing builder.directory. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [32-39] private BlockFetchRequest(Builder builder) { + if (builder.directory == null) { + throw new IllegalStateException("directory must be set before building BlockFetchRequest"); + } this.fileName = builder.fileName; this.blockFileName = builder.blockFileName; this.filePath = builder.directory.getDirectory().resolve(blockFileName); this.directory = builder.directory; this.blockSize = builder.blockSize; this.blockStart = builder.blockStart; } Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies a potential NullPointerException if builder.directory is null when build() is called. Adding a null check with a descriptive IllegalStateException is a valid defensive programming practice, though this is a placeholder class with stub implementations.	Low
General	Fix type inconsistency between builder and outer class field The Builder stores directory as FSDirectory, but the outer class field directory is typed as the broader Directory interface. The getDirectory() method returns Directory, losing the FSDirectory type information. If callers need FSDirectory-specific methods (like getDirectory() used in the constructor), this type inconsistency can cause issues. Consider making the outer class field also FSDirectory to maintain type consistency. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [25-63] -private final Directory directory; +private final FSDirectory directory; ... -public Directory getDirectory() { +public FSDirectory getDirectory() { return directory; } -... -public static final class Builder { - private FSDirectory directory; - ... - public Builder directory(FSDirectory directory) { - this.directory = directory; - return this; - } Suggestion importance[1-10]: 5 __ Why: The type inconsistency between FSDirectory in the Builder and Directory in the outer class is a valid concern, especially since the constructor calls builder.directory.getDirectory() which is an FSDirectory-specific method. Making the outer field FSDirectory would improve type consistency and avoid potential casting issues.	Low
	Initialize map field instead of assigning null The clones field is initialized to null in the placeholder constructor. Any future code that iterates or puts entries into clones without a null check will throw a NullPointerException. It should be initialized to an empty ConcurrentHashMap even in the placeholder constructor to avoid accidental NPEs during incremental development. server/src/main/java/org/opensearch/storage/indexinput/SwitchableIndexInput.java [101] -private final ConcurrentMap<SwitchableIndexInput, Boolean> clones; -... -this.clones = null; +this.clones = new java.util.concurrent.ConcurrentHashMap<>(); Suggestion importance[1-10]: 3 __ Why: While initializing clones to an empty ConcurrentHashMap instead of null is safer, the comment explicitly states this is a placeholder constructor and the real constructor will be added in a future PR. The risk of NPE during incremental development is low given the context.	Low

Suggestions up to commit f808b22

Category	Suggestion	Impact
Possible issue	Add null validation for required builder fields The constructor accesses builder.directory.getDirectory() without a null check. If directory is not set on the builder before calling build(), this will throw a NullPointerException. Add validation in the build() method or constructor to ensure required fields like directory and blockFileName are non-null before use. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [32-39] private BlockFetchRequest(Builder builder) { + if (builder.directory == null) { + throw new IllegalStateException("directory must be set"); + } + if (builder.blockFileName == null) { + throw new IllegalStateException("blockFileName must be set"); + } this.fileName = builder.fileName; this.blockFileName = builder.blockFileName; this.filePath = builder.directory.getDirectory().resolve(blockFileName); this.directory = builder.directory; this.blockSize = builder.blockSize; this.blockStart = builder.blockStart; } Suggestion importance[1-10]: 6 __ Why: The constructor accesses builder.directory.getDirectory() without null checks, which could cause NullPointerException if directory or blockFileName is not set. This is a valid defensive programming concern, though the PR is explicitly a scaffold/placeholder with full implementation deferred.	Low
General	Use consistent concrete type for directory field The outer class BlockFetchRequest stores the field directory as Directory (the base type), but the Builder uses FSDirectory (a subtype). The filePath is computed using builder.directory.getDirectory() which is an FSDirectory-specific method. Storing it as the base Directory type loses the concrete type needed for path resolution. Consider storing the field as FSDirectory to maintain type consistency and avoid potential ClassCastException if callers use getDirectory() expecting an FSDirectory. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [25-63] -private final Directory directory; +private final FSDirectory directory; ... -public Directory getDirectory() { +public FSDirectory getDirectory() { return directory; } Suggestion importance[1-10]: 5 __ Why: The directory field is declared as Directory but the builder uses FSDirectory, and getDirectory() is called on FSDirectory to resolve the path. Storing it as FSDirectory would maintain type consistency and avoid potential issues, making this a valid improvement to the type design.	Low
	Initialize clones map to avoid null dereference The clones field is initialized to null in the placeholder constructor, but it is a ConcurrentMap that will likely be iterated or accessed during clone/close operations in the implementation. Accessing a null map will cause NullPointerException. It should be initialized to a new ConcurrentHashMap<>() even in the placeholder constructor to avoid accidental NPEs if any code path touches it before the real constructor is added. server/src/main/java/org/opensearch/storage/indexinput/SwitchableIndexInput.java [61-64] private volatile boolean isClosed; private volatile boolean hasSwitchedToRemote; private volatile boolean cachedFromRemote; private final ConcurrentMap<SwitchableIndexInput, Boolean> clones; +// In the placeholder constructor: +// this.clones = new ConcurrentHashMap<>(); + Suggestion importance[1-10]: 2 __ Why: The improved_code doesn't actually change the field declaration — it only adds a comment suggesting a constructor change. The suggestion is valid in principle but the improved_code doesn't reflect the actual fix, and all methods throw UnsupportedOperationException anyway in this placeholder PR.	Low

Suggestions up to commit bcf38b7

Category	Suggestion	Impact
Possible issue	Add null validation for required builder fields The constructor accesses builder.directory without a null check, which will throw a NullPointerException if directory was not set on the builder before calling build(). Add a null check or validation in the build() method to ensure required fields like directory, fileName, and blockFileName are set before constructing the object. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [32-39] private BlockFetchRequest(Builder builder) { + Objects.requireNonNull(builder.directory, "directory must not be null"); + Objects.requireNonNull(builder.fileName, "fileName must not be null"); + Objects.requireNonNull(builder.blockFileName, "blockFileName must not be null"); this.fileName = builder.fileName; this.blockFileName = builder.blockFileName; this.filePath = builder.directory.getDirectory().resolve(blockFileName); this.directory = builder.directory; this.blockSize = builder.blockSize; this.blockStart = builder.blockStart; } Suggestion importance[1-10]: 5 __ Why: The suggestion is valid - accessing builder.directory without null check could cause NPE. However, this is a scaffold/placeholder PR where the real implementation is deferred, making this a minor concern for now. The improved_code accurately reflects the change.	Low
	Initialize concurrent map to avoid null dereference The clones field is initialized to null in the placeholder constructor, but it is a ConcurrentMap intended to track clone instances. Any future code that calls methods on clones without a null check will throw a NullPointerException. It should be initialized to a new ConcurrentHashMap<>() even in the placeholder constructor. server/src/main/java/org/opensearch/storage/indexinput/SwitchableIndexInput.java [61-64] private volatile boolean isClosed; private volatile boolean hasSwitchedToRemote; private volatile boolean cachedFromRemote; -private final ConcurrentMap<SwitchableIndexInput, Boolean> clones; +private final ConcurrentMap<SwitchableIndexInput, Boolean> clones = new ConcurrentHashMap<>(); Suggestion importance[1-10]: 3 __ Why: While the suggestion is logically sound, the improved_code changes a field declaration with initializer but the field is final and assigned in the constructor - the suggested inline initialization would conflict with the constructor assignment. Also, this is explicitly a placeholder constructor, so null initialization is intentional.	Low
General	Preserve FSDirectory type through field declaration The getDirectory() method returns the field typed as Directory, but the Builder stores it as FSDirectory. The outer class field directory is declared as Directory, losing the FSDirectory type. If callers need FSDirectory-specific methods (like getDirectory() used in the constructor), the field type should be FSDirectory to avoid unsafe casting later. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [61-63] -public Directory getDirectory() { +private final FSDirectory directory; +... +public FSDirectory getDirectory() { return directory; } Suggestion importance[1-10]: 4 __ Why: The type inconsistency between FSDirectory in the builder and Directory in the outer class is a valid design concern, as it could require unsafe casting later. However, the improved_code snippet is incomplete (uses ... which doesn't accurately show the full change), and this is a scaffold PR where the real implementation is deferred.	Low

Suggestions up to commit d940532

Category	Suggestion	Impact
Possible issue	Add null check before dereferencing builder field The constructor accesses builder.directory without a null check. If build() is called without setting the directory, this will throw a NullPointerException when calling builder.directory.getDirectory(). Add a null validation in the build() method or constructor before dereferencing builder.directory. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [32-39] private BlockFetchRequest(Builder builder) { + if (builder.directory == null) { + throw new IllegalStateException("directory must be set before building BlockFetchRequest"); + } this.fileName = builder.fileName; this.blockFileName = builder.blockFileName; this.filePath = builder.directory.getDirectory().resolve(blockFileName); this.directory = builder.directory; this.blockSize = builder.blockSize; this.blockStart = builder.blockStart; } Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies a potential NullPointerException when builder.directory is null and getDirectory() is called on it. Adding a null check improves robustness, though this is a scaffolding PR where the real constructor will be added later.	Low
General	Use AtomicBoolean for thread-safe close flag isClosed is declared as a plain volatile boolean field, but the close() method (to be implemented) will likely need a compare-and-set to avoid double-close races. Using AtomicBoolean (consistent with how CachedSwitchableIndexInput handles isClosed) would be safer and more consistent across the codebase. server/src/main/java/org/opensearch/storage/indexinput/SwitchableIndexInput.java [61-64] -private volatile boolean isClosed; +private final AtomicBoolean isClosed = new AtomicBoolean(false); private volatile boolean hasSwitchedToRemote; private volatile boolean cachedFromRemote; private final ConcurrentMap<SwitchableIndexInput, Boolean> clones; Suggestion importance[1-10]: 5 __ Why: Using AtomicBoolean for isClosed is a valid thread-safety improvement and is consistent with CachedSwitchableIndexInput. However, since this is a scaffolding PR with placeholder implementations, the actual close logic isn't present yet, making this a minor consistency improvement at this stage.	Low
	Return concrete type to avoid unsafe downcasting The getDirectory() method returns a Directory (the interface type), but the Builder stores and uses an FSDirectory. The field directory in BlockFetchRequest is declared as Directory, which loses the FSDirectory-specific type. If callers need FSDirectory-specific operations, the return type should be FSDirectory to avoid unsafe casting downstream. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [61-63] -public Directory getDirectory() { - return directory; +public FSDirectory getDirectory() { + return (FSDirectory) directory; } Suggestion importance[1-10]: 4 __ Why: The suggestion has merit since the Builder uses FSDirectory but the field is stored as Directory, potentially requiring unsafe casts downstream. However, the improved_code introduces an unchecked cast (FSDirectory) directory which is not cleaner than changing the field type directly, and this is a scaffolding PR where the design may change.	Low

Suggestions up to commit 407f405

Category	Suggestion	Impact
Possible issue	Add null check before dereferencing builder field The constructor accesses builder.directory.getDirectory() without a null check. If builder.directory is null (e.g., if the caller forgets to set it), this will throw a NullPointerException at construction time. Add a null validation in the build() method or constructor before dereferencing builder.directory. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [32-39] private BlockFetchRequest(Builder builder) { + if (builder.directory == null) { + throw new IllegalStateException("directory must be set"); + } this.fileName = builder.fileName; this.blockFileName = builder.blockFileName; this.filePath = builder.directory.getDirectory().resolve(blockFileName); this.directory = builder.directory; this.blockSize = builder.blockSize; this.blockStart = builder.blockStart; } Suggestion importance[1-10]: 5 __ Why: Adding a null check for builder.directory before calling getDirectory() is a valid defensive programming practice. However, since this is a placeholder PR with full implementation deferred, the impact is moderate and the suggestion is more of a style/robustness improvement.	Low
	Initialize concurrent map to avoid null pointer exceptions The clones map is initialized to null in the placeholder constructor. Any future code that iterates or puts into clones without a null check will throw a NullPointerException. It should be initialized to an empty ConcurrentHashMap even in the placeholder constructor to avoid accidental NPEs during incremental development. server/src/main/java/org/opensearch/storage/indexinput/SwitchableIndexInput.java [64-103] private final ConcurrentMap<SwitchableIndexInput, Boolean> clones; ... -this.clones = null; +this.clones = new java.util.concurrent.ConcurrentHashMap<>(); Suggestion importance[1-10]: 4 __ Why: Initializing clones to an empty ConcurrentHashMap instead of null in the placeholder constructor is a reasonable defensive measure. However, since this is explicitly a placeholder constructor with all methods throwing UnsupportedOperationException, the practical risk during this PR is low.	Low
General	Align field type with builder's concrete type The field directory is declared as Directory (the abstract type), but the Builder uses FSDirectory (a concrete subtype). The getDirectory() method returns the abstract Directory type, which loses the FSDirectory-specific API (e.g., getDirectory() for path resolution). Consider either declaring the field as FSDirectory to preserve the concrete type, or casting where needed. server/src/main/java/org/opensearch/storage/indexinput/BlockFetchRequest.java [25-63] -private final Directory directory; +private final FSDirectory directory; ... -public Directory getDirectory() { +public FSDirectory getDirectory() { return directory; } Suggestion importance[1-10]: 5 __ Why: The mismatch between the Directory field type and the FSDirectory builder type is a valid concern, as the constructor already calls builder.directory.getDirectory() which is FSDirectory-specific. Changing the field to FSDirectory would be more consistent and type-safe. However, the existing_code snippet spans non-contiguous lines, making it slightly imprecise.	Low

[github-actions]

❌ Gradle check result for 2f56641: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit bf3bb1e

[github-actions]

✅ Gradle check result for bf3bb1e: SUCCESS

[codecov]

Codecov Report

❌ Patch coverage is 0% with 100 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.31%. Comparing base (4198389) to head (8e579c0).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...earch/storage/indexinput/SwitchableIndexInput.java	0.00%	37 Missing ⚠️
...ensearch/storage/indexinput/BlockFetchRequest.java	0.00%	26 Missing ⚠️
...opensearch/storage/indexinput/BlockIndexInput.java	0.00%	10 Missing ⚠️
...storage/indexinput/CachedSwitchableIndexInput.java	0.00%	8 Missing ⚠️
...torage/indexinput/SwitchableIndexInputWrapper.java	0.00%	7 Missing ⚠️
...input/OnDemandPrefetchBlockSnapshotIndexInput.java	0.00%	6 Missing ⚠️
.../opensearch/storage/directory/TieredDirectory.java	0.00%	3 Missing ⚠️
...arch/storage/directory/TieredDirectoryFactory.java	0.00%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #21082      +/-   ##
============================================
+ Coverage     73.27%   73.31%   +0.03%     
+ Complexity    73220    73213       -7     
============================================
  Files          5932     5940       +8     
  Lines        333985   334085     +100     
  Branches      48138    48138              
============================================
+ Hits         244720   244925     +205     
+ Misses        69753    69566     -187     
- Partials      19512    19594      +82     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[chaitanya588]

This PR is going to implement this issue.
#21101

[github-actions]

Persistent review updated to latest commit e8f74c4

[chaitanya588]

This looks good to me.

[github-actions]

Persistent review updated to latest commit 5aa7d85

[github-actions]

❌ Gradle check result for 5aa7d85: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit 513464f

[github-actions]

❌ Gradle check result for 513464f: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit d9d8b41

[github-actions]

❌ Gradle check result for d9d8b41: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit 30a4c94

[github-actions]

✅ Gradle check result for 30a4c94: SUCCESS

[github-actions]

Persistent review updated to latest commit f66ad79

[github-actions]

❌ Gradle check result for f66ad79: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit 407f405

[github-actions]

Persistent review updated to latest commit d940532

[github-actions]

Persistent review updated to latest commit bcf38b7

[github-actions]

❌ Gradle check result for bcf38b7: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit f808b22

[github-actions]

✅ Gradle check result for f808b22: SUCCESS

[github-actions]

Persistent review updated to latest commit 8b52669

[github-actions]

❌ Gradle check result for 8b52669: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit 8e579c0

[github-actions]

❕ Gradle check result for 8e579c0: UNSTABLE

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.