Fix flaky Netty4Http3IT test suite (second attempt) by reta · Pull Request #20900 · opensearch-project/OpenSearch

reta · 2026-03-17T20:46:25Z

Description

Fix flaky Netty4Http3IT test suite (second attempt)

Related Issues

Investigates #20654

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 · 2026-03-17T20:48:04Z

PR Reviewer Guide 🔍

(Review updated until commit `242500a`)

Here are some key observations to aid the review process:

🧪 PR contains tests
🔒 No security concerns identified
✅ No TODO sections
🔀 Multiple PR themes Sub-PR theme: Fix flaky tests by adding cluster readiness checks and logger support Relevant files: modules/transport-netty4/src/internalClusterTest/java/org/opensearch/http/netty4/Netty4Http3IT.java modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java Sub-PR theme: Add bind address logging to HTTP/3 server transport Relevant files: modules/transport-netty4/src/main/java/org/opensearch/http/netty4/Netty4Http3ServerTransport.java
⚡ Recommended focus areas for review Mutable State The `logger` field in `AwaitableChannelInitializer` is package-private and set directly via field access (`handler.logger = logger`). This bypasses encapsulation and could lead to subtle bugs if the field is accessed concurrently or from subclasses unexpectedly. Consider using a constructor parameter or a setter method instead. private Logger logger; void log(Level level, String message, Object... params) { Swapped Labels In both test methods, `Netty4HttpClient.http3()` is paired with label `"h2="` and `Netty4HttpClient.https()` is paired with `"h3="`. This appears to be a copy of the original code where the labels were already swapped — `http3()` should likely be paired with `"h3="` and `https()` (HTTP/2) with `"h2="`. This mislabeling existed before but is preserved in the new code. import io.netty.handler.codec.http2.Http2ClientUpgradeCodec; import io.netty.handler.codec.http2.Http2Connection; Debug Log Left In A `logger.info` statement logging the bound socket address was added to production code. This may be intentional for diagnostics, but INFO-level logging on every bind in production could be noisy. Consider whether DEBUG level would be more appropriate, or if this log should be removed after the flakiness issue is resolved. logger.info("Bound to {}", socketAddress);

github-actions · 2026-03-17T20:48:15Z

PR Code Suggestions ✨

Latest suggestions up to 242500a

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Log actual bound address instead of requested address The `logger.info` call logs the intended bind address (`socketAddress`) rather than the actual bound address. After binding, the channel's local address may differ (e.g., if port 0 was used). Log `future.channel().localAddress()` instead to reflect the actual bound address. modules/transport-netty4/src/main/java/org/opensearch/http/netty4/Netty4Http3ServerTransport.java [233-234] ChannelFuture future = bootstrap.bind(socketAddress).sync(); -logger.info("Bound to {}", socketAddress); +logger.info("Bound to {}", future.channel().localAddress()); Suggestion importance[1-10]: 5 __ Why: Logging `future.channel().localAddress()` instead of `socketAddress` provides more accurate information about the actual bound address, which is especially useful when port 0 is used for dynamic port allocation.	Low
	Ensure thread-safe visibility of mutable logger field The `logger` field is mutable and set via `withLogger()` after construction, but `Netty4HttpClient` is used in a `try-with-resources` block and the `sendRequests` method is `synchronized`. If `withLogger` is called concurrently or the field is read before being set, there could be visibility issues. Mark the field as `volatile` to ensure safe publication across threads. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [141] -private Logger logger; +private volatile Logger logger; Suggestion importance[1-10]: 4 __ Why: While thread safety is a valid concern, in practice `withLogger()` is called immediately after construction and before any concurrent use in tests, making this a low-risk issue. The `volatile` keyword would be a minor defensive improvement.	Low
	Encapsulate logger assignment via setter method The `logger` field of `AwaitableChannelInitializer` is assigned directly via package-private field access (`handler.logger = logger`), bypassing encapsulation. Since `AwaitableChannelInitializer` already has a `log()` method, consider adding a `setLogger(Logger logger)` method to `AwaitableChannelInitializer` and using it here to maintain proper encapsulation. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [253-255] final AwaitableChannelInitializer<?> handler = handlerFactory.apply(latch, content, secure); -handler.logger = logger; +handler.setLogger(logger); clientBootstrap.handler(handler); Suggestion importance[1-10]: 3 __ Why: Direct field access to `handler.logger` bypasses encapsulation, but since both classes are private/package-private within the same file, this is a minor style concern rather than a functional issue.	Low

Previous suggestions

Suggestions up to commit 242500a

Category	Suggestion	Impact
General	Log actual bound address instead of requested address The `logger.info` call logs the `socketAddress` that was passed in, but after a successful bind the actual bound address (especially for port 0) may differ. It would be more accurate to log the actual bound address from the channel, e.g., `future.channel().localAddress()`, to avoid misleading log output. modules/transport-netty4/src/main/java/org/opensearch/http/netty4/Netty4Http3ServerTransport.java [233-234] ChannelFuture future = bootstrap.bind(socketAddress).sync(); -logger.info("Bound to {}", socketAddress); +logger.info("Bound to {}", future.channel().localAddress()); Suggestion importance[1-10]: 6 __ Why: This is a valid improvement — logging `future.channel().localAddress()` provides the actual bound address (important when port 0 is used), making the log more accurate and useful for debugging.	Low
	Ensure thread-safe visibility of mutable logger field The `logger` field is mutable and set via `withLogger()` after construction, but `Netty4HttpClient` is used in a `try-with-resources` block and the `sendRequests` method is `synchronized`. If `withLogger` is called concurrently or the field is read before being set, there could be visibility issues. Mark the field as `volatile` to ensure safe publication across threads. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [141] -private Logger logger; +private volatile Logger logger; Suggestion importance[1-10]: 4 __ Why: While thread safety is a valid concern, in practice `withLogger()` is called immediately after construction and before any concurrent use, making this a low-risk issue. The `volatile` keyword would be a minor defensive improvement.	Low
	Use setter instead of direct field access for logger The `logger` field of `AwaitableChannelInitializer` is package-private (no access modifier), but it is being set directly from the outer class `Netty4HttpClient`. Since `AwaitableChannelInitializer` is a `private static abstract` inner class, direct field access works, but it bypasses encapsulation. More critically, if `withLogger` is never called, `logger` remains `null` and the `log()` method silently does nothing — which is fine — but the direct field assignment `handler.logger = logger` could be confusing and error-prone. Consider passing the logger through the `log()` method or a setter for clarity and safety. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [253-254] final AwaitableChannelInitializer<?> handler = handlerFactory.apply(latch, content, secure); -handler.logger = logger; +handler.setLogger(logger); Suggestion importance[1-10]: 3 __ Why: Since `AwaitableChannelInitializer` is a `private static abstract` inner class, direct field access is valid Java and not a real encapsulation violation. The suggestion to add a `setLogger` method is a minor style preference with minimal practical impact.	Low

Suggestions up to commit 203a589

Category	Suggestion	Impact
Possible issue	Prevent resource leak from unselected clients The `withLogger` method mutates the existing `Netty4HttpClient` instance rather than returning a new one. Since `Netty4HttpClient.http3()` and `Netty4HttpClient.https()` create new instances, this is acceptable, but the method is called inside a `randomFrom(...)` argument list where both clients are constructed eagerly. If `withLogger` is called on a client that is not selected by `randomFrom`, the non-selected client is never closed, potentially leaking resources. The clients should be constructed and closed carefully, or the selection should happen before attaching the logger. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [88-91] -public Netty4HttpClient withLogger(Logger logger) { - this.logger = logger; - return this; -} +Netty4HttpClient http3Client = Netty4HttpClient.http3(); +Netty4HttpClient httpsClient = Netty4HttpClient.https(); +@SuppressWarnings("unchecked") +final Tuple<Netty4HttpClient, String> client = randomFrom( + Tuple.tuple(http3Client, "h2="), + Tuple.tuple(httpsClient, "h3=") +); +// Close the non-selected client +Netty4HttpClient nonSelected = client.v1() == http3Client ? httpsClient : http3Client; +nonSelected.close(); +client.v1().withLogger(logger); Suggestion importance[1-10]: 6 __ Why: This is a valid concern — both `Netty4HttpClient` instances are created eagerly inside `randomFrom(...)`, but only one is used in the `try-with-resources` block, potentially leaking the unselected client's resources. The suggested fix correctly addresses this by closing the non-selected client.	Low
General	Ensure thread-safe visibility of mutable logger field The `logger` field is mutable and set via `withLogger()` after construction, but `Netty4HttpClient` is used in a `try-with-resources` block and the `sendRequests` method is `synchronized`. If `withLogger` is called concurrently or the field is read before being set, there could be visibility issues. Mark the field as `volatile` to ensure safe publication across threads. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [141] -private Logger logger; +private volatile Logger logger; Suggestion importance[1-10]: 4 __ Why: While thread safety is a valid concern, the `logger` field is set via `withLogger()` before the client is used in a `try-with-resources` block, and `sendRequests` is `synchronized`. The risk of concurrent access is low in this test context, making `volatile` a minor improvement.	Low
General	Use setter method instead of direct field access The `logger` field of `AwaitableChannelInitializer` is package-private (no access modifier), which means it's accessed directly via field assignment. This bypasses encapsulation and could be fragile. Since `AwaitableChannelInitializer` already has a `log()` method, consider passing the logger through the constructor or a setter method instead of direct field access. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [253-254] final AwaitableChannelInitializer<?> handler = handlerFactory.apply(latch, content, secure); -handler.logger = logger; +handler.setLogger(logger); Suggestion importance[1-10]: 3 __ Why: Direct field access on `handler.logger` bypasses encapsulation, but since both `Netty4HttpClient` and `AwaitableChannelInitializer` are private/package-private classes in the same file, this is a minor style concern rather than a critical issue.	Low

Suggestions up to commit 5b66523

Category	Suggestion	Impact
Possible issue	Prevent resource leak from unused clients Both `Netty4HttpClient` instances are created eagerly when building the `randomFrom` arguments, but only one is selected and used in the try-with-resources block. The unused client is never closed, potentially leaking resources such as event loop groups and channels. Only the selected client should be created, or both should be closed. modules/transport-netty4/src/internalClusterTest/java/org/opensearch/http/netty4/Netty4Http3IT.java [89-90] -Tuple.tuple(Netty4HttpClient.http3().withLogger(logger), "h2="), -Tuple.tuple(Netty4HttpClient.https().withLogger(logger), "h3=") +int choice = random().nextInt(2); +final Tuple<Netty4HttpClient, String> client = choice == 0 + ? Tuple.tuple(Netty4HttpClient.http3().withLogger(logger), "h2=") + : Tuple.tuple(Netty4HttpClient.https().withLogger(logger), "h3="); Suggestion importance[1-10]: 8 __ Why: This is a real resource leak: both `Netty4HttpClient` instances (with their event loop groups) are created eagerly, but only one is used in the try-with-resources block. The unused client is never closed, leaking resources. The suggested fix correctly addresses this by only creating the selected client.	Medium
General	Avoid mutable state via builder method The `withLogger` method mutates the existing `Netty4HttpClient` instance after construction, which can cause race conditions if the client is shared or reused. Since `Netty4HttpClient` is used in a try-with-resources block, consider making `logger` a constructor parameter or making `withLogger` return a new instance with the logger set to ensure immutability. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [193-196] public Netty4HttpClient withLogger(Logger logger) { - this.logger = logger; - return this; + return new Netty4HttpClient(this.clientBootstrap, this.handlerFactory, this.secure, logger); } Suggestion importance[1-10]: 4 __ Why: While the immutability concern is valid in general, this is test code and the `withLogger` method is called immediately after construction before any concurrent use. The suggestion to return a new instance would require adding a new constructor, which is a reasonable refactor but has low urgency in test code.	Low
General	Use setter instead of direct field access Directly assigning to `handler.logger` accesses a package-private field from an outer class, which is fragile and bypasses encapsulation. The `logger` field should be set via the `log` method's owning class or through a dedicated setter, or passed during construction of `AwaitableChannelInitializer` to ensure proper encapsulation. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [253-255] final AwaitableChannelInitializer<?> handler = handlerFactory.apply(latch, content, secure); -handler.logger = logger; +handler.setLogger(logger); clientBootstrap.handler(handler); Suggestion importance[1-10]: 3 __ Why: The `handler.logger` direct field access works because `AwaitableChannelInitializer` is a private static inner class of `Netty4HttpClient`, so this is valid Java access within the same outer class. The encapsulation concern is overstated in this context, making this a low-impact style suggestion.	Low

Suggestions up to commit bd59477

Category	Suggestion	Impact
Possible issue	Close unused client to prevent resource leak Both `Netty4HttpClient` instances are created eagerly via `randomFrom(...)`, but only one is used inside the `try-with-resources` block. The unused client is never closed, potentially leaking resources such as `NioEventLoopGroup` threads. The non-selected client should also be closed after selection. modules/transport-netty4/src/internalClusterTest/java/org/opensearch/http/netty4/Netty4Http3IT.java [88-91] -Tuple.tuple(Netty4HttpClient.http3().withLogger(logger), "h2="), -Tuple.tuple(Netty4HttpClient.https().withLogger(logger), "h3=") +Netty4HttpClient http3Client = Netty4HttpClient.http3().withLogger(logger); +Netty4HttpClient httpsClient = Netty4HttpClient.https().withLogger(logger); +final Tuple<Netty4HttpClient, String> client = randomFrom( + Tuple.tuple(http3Client, "h2="), + Tuple.tuple(httpsClient, "h3=") +); +Netty4HttpClient unusedClient = client.v1() == http3Client ? httpsClient : http3Client; +unusedClient.close(); Suggestion importance[1-10]: 7 __ Why: Both `Netty4HttpClient` instances (each with a `NioEventLoopGroup`) are created but only one is used in the `try-with-resources` block, leaving the other unclosed and leaking thread resources. This is a real resource leak that should be addressed.	Medium
General	Encapsulate direct field access with a setter The `logger` field in `AwaitableChannelInitializer` is assigned directly via `handler.logger = logger` (package-private field access) in `sendRequests`. This breaks encapsulation and is error-prone. It should be set through a constructor parameter or a setter method to make the API explicit and safe. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [351-352] private static abstract class AwaitableChannelInitializer<C extends Channel> extends ChannelInitializer<C> { private Logger logger; + void setLogger(Logger logger) { + this.logger = logger; + } + Suggestion importance[1-10]: 4 __ Why: Direct field access via `handler.logger = logger` breaks encapsulation, and adding a setter would be a cleaner design. However, since both classes are in the same file and `AwaitableChannelInitializer` is a private static inner class, this is a minor style concern rather than a critical issue.	Low
General	Ensure thread-safe visibility of logger field The `logger` field is mutable and set via `withLogger()` after construction, but `Netty4HttpClient` is used in a `try-with-resources` block and `sendRequests` is synchronized. If `withLogger` is called after `sendRequests` starts (unlikely but possible), there's a visibility issue. More critically, `withLogger` returns `this` but the field assignment is not thread-safe. Consider making `logger` `volatile` to ensure visibility across threads. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [141] -private Logger logger; +private volatile Logger logger; -Netty4HttpClient( - Bootstrap clientBootstrap, - TriFunction<CountDownLatch, Collection<FullHttpResponse>, Boolean, AwaitableChannelInitializer<?>> handlerFactory, - Suggestion importance[1-10]: 3 __ Why: While making `logger` `volatile` is a valid thread-safety concern, in practice `withLogger()` is called before any `sendRequests` invocation in the test code, making this a low-impact improvement. The suggestion is technically correct but the risk is minimal in this test context.	Low

Suggestions up to commit 982c852

Category	Suggestion	Impact
General	Use parameterized logging instead of concatenation String concatenation in logging calls is inefficient because the string is always constructed even when the log level is disabled. Use parameterized logging instead to defer string construction. modules/transport-netty4/src/test/java/org/opensearch/http/netty4/Netty4HttpClient.java [524] -logger.info("Connecting to: " + channel.remoteAddress()); +logger.info("Connecting to: {}", channel.remoteAddress()); Suggestion importance[1-10]: 5 __ Why: Using parameterized logging (`{}`) instead of string concatenation is a best practice that avoids unnecessary string construction when the log level is disabled. This is a minor but valid improvement to logging efficiency.	Low

github-actions · 2026-03-17T20:54:49Z

❌ Gradle check result for ce6727b: 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 · 2026-03-17T21:06:30Z

Persistent review updated to latest commit 550a3b5

github-actions · 2026-03-17T21:46:13Z

❌ Gradle check result for 550a3b5: 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 · 2026-03-18T03:02:59Z

❌ Gradle check result for 550a3b5: 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 · 2026-03-18T19:03:05Z

Persistent review updated to latest commit 982c852

github-actions · 2026-03-18T20:21:52Z

❌ Gradle check result for 982c852: 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 · 2026-03-18T21:38:31Z

❌ Gradle check result for 982c852: 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 · 2026-03-19T01:08:37Z

Persistent review updated to latest commit bd59477

github-actions · 2026-03-19T03:10:00Z

❌ Gradle check result for bd59477: null

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 · 2026-03-19T12:34:54Z

❌ Gradle check result for bd59477: 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 · 2026-03-19T12:41:24Z

Persistent review updated to latest commit 5b66523

github-actions · 2026-03-19T13:48:36Z

❌ Gradle check result for 5b66523: 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 · 2026-03-19T13:50:48Z

Persistent review updated to latest commit 203a589

github-actions · 2026-03-19T15:05:09Z

❌ Gradle check result for 203a589: 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 · 2026-03-19T16:37:36Z

❌ Gradle check result for 203a589: 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 · 2026-03-19T18:30:12Z

❌ Gradle check result for 203a589: 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 · 2026-03-19T20:24:11Z

❌ Gradle check result for 203a589: 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?

Signed-off-by: Andriy Redko <drreta@gmail.com>

github-actions · 2026-03-19T21:47:02Z

Persistent review updated to latest commit 242500a

github-actions · 2026-03-19T22:57:23Z

❌ Gradle check result for 242500a: 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 · 2026-03-20T01:33:24Z

✅ Gradle check result for 242500a: SUCCESS

codecov · 2026-03-20T02:34:29Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.83%. Comparing base (9f5d0e1) to head (242500a).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #20900      +/-   ##
============================================
+ Coverage     73.30%   73.83%   +0.52%     
- Complexity    72484    73026     +542     
============================================
  Files          5819     5819              
  Lines        331155   331353     +198     
  Branches      47840    47875      +35     
============================================
+ Hits         242769   244659    +1890     
+ Misses        68876    67538    -1338     
+ Partials      19510    19156     -354

☔ 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.

github-actions · 2026-03-20T11:56:41Z

❌ Gradle check result for 242500a: 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 · 2026-03-20T13:08:51Z

❌ Gradle check result for 242500a: 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 · 2026-03-20T14:31:53Z

✅ Gradle check result for 242500a: SUCCESS

github-actions · 2026-03-20T14:34:52Z

Persistent review updated to latest commit 242500a

github-actions · 2026-03-20T16:49:21Z

❌ Gradle check result for 242500a: 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?

reta · 2026-03-20T17:00:02Z

@andrross I highly suspect the changes in this pull request may not fix the issue but I have added some diagnostic info to capture what exactly could be the cause, it should help to work towards permanent fix (I sadly never was able to reproduce the issue).

andrross · 2026-03-20T17:04:04Z

FYI @reta, I've had some success reproducing these hard-to-repro failures by running the test on a remote machine and then using stress-ng to more or less fully utilize every CPU core.

github-actions · 2026-03-20T18:09:27Z

✅ Gradle check result for 242500a: SUCCESS

reta · 2026-03-20T18:21:59Z

FYI @reta, I've had some success reproducing these hard-to-repro failures by running the test on a remote machine and then using stress-ng to more or less fully utilize every CPU core.

Thanks @andrross, I did pursue similar paths as well (cutting active cpu count, disabling C1/C2, running many tests parallel at 100% CPU utilization), but literally no luck

Signed-off-by: Andriy Redko <drreta@gmail.com> (cherry picked from commit a60cecd) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

reta added flaky-test Random test failure that succeeds on second run skip-changelog labels Mar 17, 2026

github-actions bot added >test-failure Test failure from CI, local build, etc. autocut labels Mar 17, 2026

reta force-pushed the 20654-2 branch from ce6727b to 550a3b5 Compare March 17, 2026 21:04

opensearch-ci-bot mentioned this pull request Mar 18, 2026

[AUTOCUT] Gradle Check Flaky Test Report for AzureBlobStoreRepositoryTests #14291

Open

reta force-pushed the 20654-2 branch from 550a3b5 to 982c852 Compare March 18, 2026 19:01

reta force-pushed the 20654-2 branch 2 times, most recently from 4a9a15c to bd59477 Compare March 19, 2026 01:06

opensearch-ci-bot mentioned this pull request Mar 19, 2026

[AUTOCUT] Gradle Check Flaky Test Report for IndicesRequestCacheIT #14288

Open

reta force-pushed the 20654-2 branch from bd59477 to 5b66523 Compare March 19, 2026 12:40

reta force-pushed the 20654-2 branch from 5b66523 to 203a589 Compare March 19, 2026 13:49

opensearch-ci-bot mentioned this pull request Mar 19, 2026

[AUTOCUT] Gradle Check Flaky Test Report for WritableWarmIT #15846

Open

opensearch-ci-bot mentioned this pull request Mar 19, 2026

[AUTOCUT] Gradle Check Flaky Test Report for FlightMetricsTests #18947

Open

Fix flaky Netty4Http3IT test suite (second attempt)

242500a

Signed-off-by: Andriy Redko <drreta@gmail.com>

reta force-pushed the 20654-2 branch from 203a589 to 242500a Compare March 19, 2026 21:45

reta marked this pull request as ready for review March 20, 2026 16:58

reta requested review from a team and peternied as code owners March 20, 2026 16:58

andrross approved these changes Mar 20, 2026

View reviewed changes

reta merged commit a60cecd into opensearch-project:main Mar 20, 2026
66 of 75 checks passed

reta added the backport 3.5 Backport to 3.5 branch label Mar 20, 2026

opensearch-trigger-bot bot mentioned this pull request Mar 20, 2026

[Backport 3.5] Fix flaky Netty4Http3IT test suite (second attempt) #20947

Open

opensearch-ci-bot mentioned this pull request Mar 20, 2026

[AUTOCUT] Gradle Check Flaky Test Report for RemoteStoreStatsIT #14310

Open

Conversation

reta commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issues

Check List

Uh oh!

github-actions bot commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Reviewer Guide 🔍

(Review updated until commit 242500a)

Uh oh!

github-actions bot commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Code Suggestions ✨

Previous suggestions

Uh oh!

github-actions bot commented Mar 17, 2026

Uh oh!

github-actions bot commented Mar 17, 2026

Uh oh!

github-actions bot commented Mar 17, 2026

Uh oh!

github-actions bot commented Mar 18, 2026

Uh oh!

github-actions bot commented Mar 18, 2026

Uh oh!

github-actions bot commented Mar 18, 2026

Uh oh!

github-actions bot commented Mar 18, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 19, 2026

Uh oh!

github-actions bot commented Mar 20, 2026

Uh oh!

codecov bot commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

github-actions bot commented Mar 20, 2026

Uh oh!

github-actions bot commented Mar 20, 2026

Uh oh!

github-actions bot commented Mar 20, 2026

Uh oh!

github-actions bot commented Mar 20, 2026

Uh oh!

github-actions bot commented Mar 20, 2026

Uh oh!

reta commented Mar 20, 2026

Uh oh!

andrross commented Mar 20, 2026

Uh oh!

github-actions bot commented Mar 20, 2026

Uh oh!

reta commented Mar 20, 2026

Uh oh!

Uh oh!

reta commented Mar 17, 2026 •

edited

Loading

github-actions bot commented Mar 17, 2026 •

edited

Loading

(Review updated until commit `242500a`)

github-actions bot commented Mar 17, 2026 •

edited

Loading

codecov bot commented Mar 20, 2026 •

edited

Loading