fix: Separate internal ignore settings from user ignore settings in restore

[piyushk6130]

Description

This PR fixes an issue where internal ignore settings were being blocked by user-unremovable settings protection during snapshot restore operations.

Problem

When restoring snapshots across clusters (e.g., from a remote-store enabled cluster to a non-remote-store cluster), internal settings like index.remote_store.* need to be filtered out. However, the current implementation combines internal ignore settings with user ignore settings, causing internal settings to be blocked by the USER_UNREMOVABLE_SETTINGS protection check.

Solution

Separate internal ignore settings into their own filter lists (internalKeyFilters and internalSimpleMatchPatterns) that are evaluated first and bypass the user-unremovable settings protection. This ensures:

Internal ignore settings (like index.remote_store.*) are always filtered regardless of protection status
User ignore settings continue to respect the USER_UNREMOVABLE_SETTINGS protection
Testing

Manually tested cross-cluster restore scenarios:

Remote store → Non-remote store: Remote store settings correctly stripped ✓
Non-remote store → Remote store: Settings correctly applied by target cluster ✓
Remote store → Remote store: Settings preserved ✓
Non-remote store → Non-remote store: No changes ✓

[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

The change introduces separate internal and user-facing ignore settings lists in RestoreService. Internal ignore patterns are collected separately and applied first in the filtering logic, while user-protected settings protection semantics are preserved. No public API modifications.

Changes

Cohort / File(s)	Summary
Settings Filtering Logic server/src/main/java/org/opensearch/snapshots/RestoreService.java	Introduces internalKeyFilters and internalSimpleMatchPatterns lists to segregate internal ignore settings. Updates filtering logic to apply internal ignore patterns with override precedence, followed by user ignore patterns for non-protected settings. Minor structural adjustments to comments and method organization.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: separating internal ignore settings from user ignore settings in the restore process.
Description check	✅ Passed	The description includes all required sections with detailed problem statement, solution explanation, and manual testing results; minor testing checklist items not explicitly marked but testing is documented.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

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

✨ Finishing touches

🧪 Generate unit tests (beta)

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

---

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 1dfa515: 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]

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

[opensearch-trigger-bot]

This PR is stalled because it has been open for 30 days with no activity.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Behavior Change The new settingsFilter no longer excludes settings matching indexScopedSettings.isUnmodifiableOnRestoreSetting(k) from user ignore patterns via a dynamic per-key check. Instead, protection is computed once from settings.keySet() at filter-build time. If a user's simple-match pattern (e.g. index.*) could match an unmodifiable-on-restore setting that is not present in the current index settings but is present elsewhere, it would previously be protected but is now filterable. Confirm whether iterating only settings.keySet() captures all keys the filter will be applied to (it is used on both settings and normalizedChangeSettings), since keys in normalizedChangeSettings that are unmodifiable-on-restore may not be included in protectedSettings. // Build combined protected settings set including dynamic unmodifiable settings Set<String> protectedSettings = new HashSet<>(USER_UNREMOVABLE_SETTINGS); for (String key : settings.keySet()) { if (indexScopedSettings.isUnmodifiableOnRestoreSetting(key)) { protectedSettings.add(key); } } Predicate<String> settingsFilter = createSettingsFilterPredicate( ignoreSettings, ignoreSettingsInternal, protectedSettings );

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Preserve dynamic unmodifiable-on-restore checks The protectedSettings set is built by iterating over settings.keySet(), which only captures unmodifiable-on-restore keys currently present in the index settings. The original predicate called indexScopedSettings.isUnmodifiableOnRestoreSetting(k) for every key being tested, which also protects settings from normalizedChangeSettings or any key not already in settings. Pass a predicate/reference to indexScopedSettings into createSettingsFilterPredicate (or evaluate isUnmodifiableOnRestoreSetting inside the predicate) so that dynamic protection semantics are preserved for all keys, not just those currently in the snapshot settings. server/src/main/java/org/opensearch/snapshots/RestoreService.java [910-916] -// Build combined protected settings set including dynamic unmodifiable settings -Set<String> protectedSettings = new HashSet<>(USER_UNREMOVABLE_SETTINGS); -for (String key : settings.keySet()) { - if (indexScopedSettings.isUnmodifiableOnRestoreSetting(key)) { - protectedSettings.add(key); - } -} +Predicate<String> isUnmodifiableOnRestore = indexScopedSettings::isUnmodifiableOnRestoreSetting; +Predicate<String> settingsFilter = createSettingsFilterPredicate( + ignoreSettings, + ignoreSettingsInternal, + USER_UNREMOVABLE_SETTINGS, + isUnmodifiableOnRestore +); Suggestion importance[1-10]: 8 __ Why: Valid concern: the original predicate dynamically checked isUnmodifiableOnRestoreSetting(k) for every key, while the new implementation only pre-populates protection for keys already in settings.keySet(). This could weaken protection for keys from normalizedChangeSettings or other sources, though the filter is applied via settings.filter(...) which limits practical impact.	Medium

[github-actions]

❕ Gradle check result for 858a5a5: 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.

[codecov]

Codecov Report

❌ Patch coverage is 75.75758% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.45%. Comparing base (95ece9b) to head (858a5a5).

Files with missing lines	Patch %	Lines
.../java/org/opensearch/snapshots/RestoreService.java	75.75%	4 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #20494   +/-   ##
=========================================
  Coverage     73.44%   73.45%           
+ Complexity    76114    76099   -15     
=========================================
  Files          6076     6076           
  Lines        345508   345523   +15     
  Branches      49732    49737    +5     
=========================================
+ Hits         253773   253790   +17     
- Misses        71497    71503    +6     
+ Partials      20238    20230    -8     

☔ View full report in Codecov by Harness.
📢 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.