Disable Segment Replication Backpressure check for Warm Index

[Gagan6164]

Description

Disable Segment Replication Backpressure check for Warm Index

Related Issues

Resolves

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.

Summary by CodeRabbit

• Refactor
  • Added comprehensive warm node support to the cluster replication framework with enhanced configuration identification and handling capabilities. Optimized bulk action processing specifically for warm nodes through adjusted backpressure mechanisms and refined control flow logic, improving overall resource utilization and operational performance characteristics across distributed warm node cluster deployments and configurations.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The changes add warm node detection to the replication action framework and modify bulk shard action logic to bypass segment replication and remote store backpressure checks when executing on warm nodes, while preserving existing behavior for non-warm nodes.

Changes

Cohort / File(s)	Summary
Warm node field initialization server/src/main/java/org/opensearch/action/support/replication/TransportReplicationAction.java	Added isWarmNode boolean field initialized in constructor via static isWarmNode(settings) method from DiscoveryNode utility class.
Backpressure check bypass server/src/main/java/org/opensearch/action/bulk/TransportShardBulkAction.java	Modified primary limits check condition to additionally skip backpressure validations when isWarmNode is true, bypassing segment replication and remote store backpressure checks on warm nodes only.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Backpressure bypass logic: Verify the conditional logic correctly identifies warm nodes and that skipping these checks is the intended behavior
• Impact on replication: Ensure bypassing backpressure checks on warm nodes does not create unexpected performance or consistency issues
• Field initialization: Confirm the isWarmNode field is properly propagated through the replication action hierarchy

Suggested reviewers

• msfroh
• sachinpkale
• shwetathareja
• andrross
• dbwiddis
• cwperks

Poem

🐰 Warm nodes skip the pressure gates,
No backpressure slows their fate,
Through replication's gentle flow,
Faster now, off they go! ✨

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description lacks substantive content; it merely repeats the title and has an empty 'Related Issues' section with no issue reference, making it incomplete and vague.	Fill in the 'Related Issues' section with the issue number this PR resolves and expand the Description section with details about what changes were made and why.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The pull request title accurately and specifically describes the main change: disabling segment replication backpressure checks for warm nodes.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

server/src/main/java/org/opensearch/action/support/replication/TransportReplicationAction.java (1)

103-103: Warm-node flag wiring looks correct; consider clarifying node-vs-index semantics

The new isWarmNode field is cleanly wired (static helper, final field, ctor init from settings) and safe to use from subclasses; no correctness concerns.

Given the PR intent (“Warm Index”) but a node-level flag, it may be worth a short field Javadoc or slightly more explicit name (e.g., isWarmTierNode) to avoid future confusion with any potential per-index “warm” notion.

Also applies to: 156-156, 259-259

server/src/main/java/org/opensearch/action/bulk/TransportShardBulkAction.java (1)

570-579: Backpressure bypass on warm nodes is correctly scoped; add rationale comment and confirm node-level intent

The updated guard:

if (force(request) == false && isWarmNode == false) {
    ...
}

preserves existing behavior for non‑warm nodes and cleanly disables both segment replication and remote store backpressure checks on warm nodes, while still delegating to super.checkPrimaryLimits(...) for other protections. Functionally this matches the stated goal and looks correct.

Two minor suggestions:

• Add a brief comment above this if explaining that warm-tier nodes intentionally bypass segrep/remote-store backpressure (e.g., due to expected IO profile or isolation of warm workloads).
• Re-check with the product/architectural intent that the bypass should be node-wide (all shards on a warm node) rather than strictly tied to specific “warm” indices; if the latter is ever required, this is the hook where an index-aware condition could be introduced.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1ee30dc and f8f8a48.

📒 Files selected for processing (2)

• server/src/main/java/org/opensearch/action/bulk/TransportShardBulkAction.java (1 hunks)
• server/src/main/java/org/opensearch/action/support/replication/TransportReplicationAction.java (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (20)

• GitHub Check: gradle-check
• GitHub Check: Analyze (java)
• GitHub Check: detect-breaking-change
• GitHub Check: assemble (25, ubuntu-24.04-arm)
• GitHub Check: assemble (21, windows-latest)
• GitHub Check: precommit (25, macos-15-intel)
• GitHub Check: assemble (25, windows-latest)
• GitHub Check: precommit (25, ubuntu-24.04-arm)
• GitHub Check: assemble (25, ubuntu-latest)
• GitHub Check: precommit (21, ubuntu-latest)
• GitHub Check: precommit (21, windows-2025, true)
• GitHub Check: assemble (21, ubuntu-24.04-arm)
• GitHub Check: precommit (21, ubuntu-24.04-arm)
• GitHub Check: precommit (21, macos-15)
• GitHub Check: precommit (21, macos-15-intel)
• GitHub Check: assemble (21, ubuntu-latest)
• GitHub Check: precommit (25, macos-15)
• GitHub Check: precommit (25, windows-latest)
• GitHub Check: precommit (25, ubuntu-latest)
• GitHub Check: precommit (21, windows-latest)

[github-actions]

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