Add hook to provide GrpcInterceptorProvider Settings

[finnegancarroll]

Description

Plugins implementing a GrpcInterceptorProvider may want their interceptor behavior to depend on settings.
This change adds an initSettings hook called on GrpcPlugin.createComponents which provides these interceptors visibility into settings.

Related Issues

N/A

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.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• 🔍 Trigger a full review

📝 Walkthrough

Walkthrough

This change introduces settings initialization support for gRPC interceptor providers by adding a default initSettings() method to the GrpcInterceptorProvider interface and integrating it into the component creation flow to pass node settings to providers before interceptor collection.

Changes

Cohort / File(s)	Summary
Interface - Settings Initialization Support modules/transport-grpc/spi/src/main/java/org/opensearch/transport/grpc/spi/GrpcInterceptorProvider.java	Added default method initSettings(Settings settings) that returns this, allowing providers to receive and act on node Settings. Added import for org.opensearch.common.settings.Settings.
Plugin Integration modules/transport-grpc/src/main/java/org/opensearch/transport/grpc/GrpcPlugin.java	Modified component creation to call provider.initSettings(environment.settings()) on each interceptor provider before collecting ordered interceptors, ensuring providers receive configuration settings prior to building their interceptor lists.
Test Coverage modules/transport-grpc/src/test/java/org/opensearch/transport/grpc/GrpcPluginTests.java	Added TestSettingsAwareInterceptorProvider implementation that captures settings and enforces a boolean "test-setting" requirement. Added test method testGrpcInterceptorProviderSettingsInitialization() verifying settings initialization succeeds with valid settings and raises RuntimeException with invalid or empty settings.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding an initSettings hook to provide GrpcInterceptorProvider access to settings.
Description check	✅ Passed	The description covers the key aspects: explains what the change achieves, marks related issues as N/A, and completes all checklist items appropriately.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[github-actions]

❌ Gradle check result for 9e74427: 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]

❌ Gradle check result for 79cfd87: 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]

❌ Gradle check result for 79cfd87: 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]

✅ Gradle check result for 79cfd87: SUCCESS

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.24%. Comparing base (672039d) to head (f242662).
⚠️ Report is 13 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #20493      +/-   ##
============================================
- Coverage     73.25%   73.24%   -0.01%     
+ Complexity    71979    71966      -13     
============================================
  Files          5796     5797       +1     
  Lines        329287   329329      +42     
  Branches      47419    47430      +11     
============================================
  Hits         241203   241203              
- Misses        68759    68792      +33     
- Partials      19325    19334       +9     

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

[prudhvigodithi]

At high level LGTM, @finnegancarroll can you fix the codecov ?

[finnegancarroll]

Thanks for taking a look @prudhvigodithi , adding a small unit test to bolster code cov here. This line seems to functionally used all over the tests but with objects that are provided by Mockito which confuses code cov.

[github-actions]

✅ Gradle check result for f242662: SUCCESS