Fix default value for some settings when filtered#137652
Merged
jordan-powers merged 13 commits intoelastic:mainfrom Nov 17, 2025
Merged
Fix default value for some settings when filtered#137652jordan-powers merged 13 commits intoelastic:mainfrom
jordan-powers merged 13 commits intoelastic:mainfrom
Conversation
jordan-powers
added
>bug
:Core/Infra/Settings
elasticsearchmachine
added
v9.2.2
v9.3.0
v8.19.8
v9.1.8
and removed
branch:9.2
branch:9.1
branch:8.19
labels
Collaborator
|
Hi @jordan-powers, I've created a changelog YAML for you. |
jordan-powers
added
the
auto-backport
…beyond-limit-default-value
Collaborator
|
Hi @jordan-powers, I've updated the changelog YAML for you. |
Collaborator
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
Contributor
|
Thanks @jordan-powers! |
Collaborator
|
Hi @jordan-powers, I've updated the changelog YAML for you. |
…beyond-limit-default-value
mosche
approved these changes
Nov 14, 2025
Contributor
mosche
left a comment
mosche
left a comment
There was a problem hiding this comment.
Thanks again for the fix!
I just pointed out some minor nits on the new test case, looking good otherwise :)
| public void testGetDefaultValueWhenDependentOnOtherSettings() { | ||
| final String indexName = "test-index-1"; | ||
|
|
||
| String[][] expectedSettings = { |
Contributor
There was a problem hiding this comment.
Thanks for adding the test!
Though, a nit on that. Could you assert that the filtered response contains nothing else than the filtered key.
That should be fairly easy if making expectedSettings a Settings object. That way lists are also properly supported.
Settings expectedSettings = Settings.builder()
.put("index.mapping.source.mode", "SYNTHETIC")
...
.build();
...
for (String key : expectedSettings.keySet()) {
...
Map<String, Settings> expectedResponse = Map.of(indexName, expectedSettings.filter(key::equals));
assertThat(
filteredResponse,
Matchers.either(LambdaMatchers.transformedMatch(GetSettingsResponse::getIndexToSettings, equalTo(expectedResponse)))
.or(LambdaMatchers.transformedMatch(GetSettingsResponse::getIndexToDefaultSettings, equalTo(expectedResponse)))
);
}
Contributor
There was a problem hiding this comment.
I'm also wondering how stable these settings will be for index modelogsdb.
If there are settings that are more likely to change, we should better not check them here as that would lead to a rather unexpected place for test failures.
Contributor
Author
There was a problem hiding this comment.
I believe these settings should be fairly stable, so it'd be ok to check them here.
|
|
||
| assertAcked(prepareCreate(indexName).setSettings(Settings.builder().put("index.mode", "logsdb")).get()); | ||
| for (String[] expectedSetting : expectedSettings) { | ||
| GetSettingsResponse unfilteredResponse = indicesAdmin().getSettings( |
Contributor
There was a problem hiding this comment.
nit, this could move out of the loop
…beyond-limit-default-value
…beyond-limit-default-value
…beyond-limit-default-value
This was referenced Nov 17, 2025
Collaborator
jordan-powers
added a commit
to jordan-powers/elasticsearch
that referenced
this pull request
Nov 17, 2025
Some settings (such as index.mapping.total_fields. ignore_dynamic_beyond_limit) rely on the value of other settings to determine their default value. When retrieving a setting value or default, the api allows the user to specify a filter, and the returned settings object will be filtered to only include the relevant setting. However, we are currently applying this filter to the settings object that we pass to the defaults providers. This means that the other setting(s) which determines the default value for the dependent setting might be hidden by the filter, and so an incorrect default will be returned. This PR fixes that logic so that the unfiltered set of all set settings is passed into the default values provider.
jordan-powers
added a commit
to jordan-powers/elasticsearch
that referenced
this pull request
Nov 17, 2025
Some settings (such as index.mapping.total_fields. ignore_dynamic_beyond_limit) rely on the value of other settings to determine their default value. When retrieving a setting value or default, the api allows the user to specify a filter, and the returned settings object will be filtered to only include the relevant setting. However, we are currently applying this filter to the settings object that we pass to the defaults providers. This means that the other setting(s) which determines the default value for the dependent setting might be hidden by the filter, and so an incorrect default will be returned. This PR fixes that logic so that the unfiltered set of all set settings is passed into the default values provider.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Nov 17, 2025
…138195) * Fix default value for some settings when filtered (#137652) Some settings (such as index.mapping.total_fields. ignore_dynamic_beyond_limit) rely on the value of other settings to determine their default value. When retrieving a setting value or default, the api allows the user to specify a filter, and the returned settings object will be filtered to only include the relevant setting. However, we are currently applying this filter to the settings object that we pass to the defaults providers. This means that the other setting(s) which determines the default value for the dependent setting might be hidden by the filter, and so an incorrect default will be returned. This PR fixes that logic so that the unfiltered set of all set settings is passed into the default values provider. * Fix test compile error * Remove settings that haven't been backported from test
elasticsearchmachine
pushed a commit
that referenced
this pull request
Nov 17, 2025
…38196) * Fix default value for some settings when filtered (#137652) Some settings (such as index.mapping.total_fields. ignore_dynamic_beyond_limit) rely on the value of other settings to determine their default value. When retrieving a setting value or default, the api allows the user to specify a filter, and the returned settings object will be filtered to only include the relevant setting. However, we are currently applying this filter to the settings object that we pass to the defaults providers. This means that the other setting(s) which determines the default value for the dependent setting might be hidden by the filter, and so an incorrect default will be returned. This PR fixes that logic so that the unfiltered set of all set settings is passed into the default values provider. * Remove settings that haven't been backported from test
elasticsearchmachine
pushed a commit
that referenced
this pull request
Nov 18, 2025
…38194) * Fix default value for some settings when filtered (#137652) Some settings (such as index.mapping.total_fields. ignore_dynamic_beyond_limit) rely on the value of other settings to determine their default value. When retrieving a setting value or default, the api allows the user to specify a filter, and the returned settings object will be filtered to only include the relevant setting. However, we are currently applying this filter to the settings object that we pass to the defaults providers. This means that the other setting(s) which determines the default value for the dependent setting might be hidden by the filter, and so an incorrect default will be returned. This PR fixes that logic so that the unfiltered set of all set settings is passed into the default values provider. * Remove settings that haven't been backported from test
jordan-powers
deleted the
fix-ignore-default-beyond-limit-default-value
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some settings (such as
index.mapping.total_fields.ignore_dynamic_beyond_limit) rely on the value of other settings to determine their default value.When retrieving a setting value or default, the api allows the user to specify a filter, and the returned settings object will be filtered to only include the relevant setting.
However, we are currently applying this filter to the settings object that we pass to the defaults providers. This means that the other setting(s) which determines the default value for the dependent setting might be hidden by the filter, and so an incorrect default will be returned.
This PR fixes that logic so that the unfiltered set of all set settings is passed into the default values provider.
Fixes #136333