Add explicit isNoOpUpdate() method to MapperService#144113
Merged
elasticsearchmachine merged 7 commits intoelastic:mainfrom Mar 16, 2026
Merged
Add explicit isNoOpUpdate() method to MapperService#144113elasticsearchmachine merged 7 commits intoelastic:mainfrom
elasticsearchmachine merged 7 commits intoelastic:mainfrom
Conversation
We currently check that a mapping update will be applied and that it is not a no-op by calling MapperService.merge() with a special merge reason. All other calls to merge() will update the state of the MapperService, but this just does preflight checks. This can be confusing when reading code - it's not necessarily obvious if a call to merge() is going to change state or not. To make this clearer, we separate preflight checks that don't change state, and real merges that do change state, into separate method calls.
romseygeek
added
>non-issue
:StorageEngine/Mapping
Collaborator
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
Contributor
Author
|
@drempapis would appreciate your eyes on this, given the fix you merged this morning! |
drempapis
reviewed
Mar 13, 2026
| } | ||
|
|
||
| private DocumentMapper doMerge(String type, MergeReason reason, Map<String, Object> mappingSourceAsMap) { | ||
| assert reason != MergeReason.MAPPING_AUTO_UPDATE_PREFLIGHT; |
Contributor
There was a problem hiding this comment.
Is this assert enough? Should it be replaced by a runtime check, throwing an exception?
Contributor
Author
There was a problem hiding this comment.
An assertion should be fine I think, MergeReason is entirely internal.
drempapis
reviewed
Mar 13, 2026
| // returning the current document mapper as the merge result to simulate a noop mapping update | ||
| when(mapperService.documentMapper()).thenReturn(documentMapper); | ||
| when(mapperService.merge(any(), any(CompressedXContent.class), any())).thenReturn(documentMapper); | ||
| when(mapperService.isNoOpUpdate(any())).thenReturn(true); |
Contributor
There was a problem hiding this comment.
That behavior already existed, but I think we should remove the mockito framework.
Contributor
Author
There was a problem hiding this comment.
Yep, good idea. There are several tests in here that use Mockito so I think probably it's best done as a follow-up covering all of them, to keep things separate?
Contributor
There was a problem hiding this comment.
Yes, this should be done in a follow-up pr
romseygeek
added
the
auto-merge-without-approval
szybia
added a commit
to szybia/elasticsearch
that referenced
this pull request
Mar 16, 2026
…elocations * upstream/main: (33 commits) Unmute InferenceRestIT and DefaultEndPointsIT (elastic#144217) feat: add keep_alive to async task status (elastic#144010) Add explicit isNoOpUpdate() method to MapperService (elastic#144113) Always attach APM Agent (elastic#144120) Fix random_score nightly tests (elastic#144176) Add nested query checks for disabled sequence numbers (elastic#144185) Return sentinel values from Fetch when sequence numbers are disabled (elastic#144212) [Test] Test peer-recovery with sequence numbers pruning (elastic#144116) Remove `scaled-*` field assertions from mixed cluster downsampling test (elastic#144295) Refactor: Use range syntax in ES|QL exponential histogram tests (elastic#144110) Move resolve aliases to IndexAbstractionOptions (elastic#143953) unmute test (elastic#144299) Fix approximation csvtests (elastic#144233) fix test (elastic#144171) Add int4 vector scoring benchmarks (elastic#144105) Mute org.elasticsearch.xpack.esql.qa.single_node.GenerativeIT test elastic#143023 Mute org.elasticsearch.test.apmintegration.MetricsApmIT testApmIntegration {withOTel=false} elastic#144282 Native cli launcher (elastic#143712) Mute org.elasticsearch.xpack.esql.qa.multi_node.GenerativeIT test elastic#143023 Mute org.elasticsearch.xpack.esql.heap_attack.HeapAttackSubqueryIT testManyRandomKeywordFieldsInSubqueryIntermediateResults elastic#144274 ...
michalborek
pushed a commit
to michalborek/elasticsearch
that referenced
this pull request
Mar 23, 2026
We currently check that a mapping update will be applied and that it is not a no-op by calling MapperService.merge() with a special merge reason. All other calls to merge() will update the state of the MapperService, but this just does preflight checks. This can be confusing when reading code - it's not necessarily obvious if a call to merge() is going to change state or not. To make this clearer, we separate preflight checks that don't change state, and real merges that do change state, into separate method calls.
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
4 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.
We currently check that a mapping update will be applied and that it is not a no-op by calling MapperService.merge() with a special merge reason. All other calls to merge() will update the state of the MapperService, but this just does preflight checks. This can be confusing when reading code - it's not necessarily obvious if a call to merge() is going to change state or not. To make this clearer, we separate preflight checks that don't change state, and real merges that do change state, into separate method calls.