Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check object depth limit at parse time #90285

Merged
merged 4 commits into from
Sep 26, 2022
Merged

Conversation

ywelsch
Copy link
Contributor

@ywelsch ywelsch commented Sep 23, 2022

Helps avoiding stack overflow errors when the total field limit is set too high.

Relates #87926

@elasticsearchmachine elasticsearchmachine added v8.6.0 needs:triage Requires assignment of a team area label labels Sep 23, 2022
@ywelsch ywelsch added >non-issue :Search Foundations/Mapping Index mappings, including merging and defining field types and removed needs:triage Requires assignment of a team area label labels Sep 23, 2022
@elasticsearchmachine elasticsearchmachine added the Team:Search Meta label for search team label Sep 23, 2022
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search (Team:Search)

Copy link
Contributor

@romseygeek romseygeek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Maybe worth adding a test to check that this doesn't trip when we have a multiple-dotted field name underneath an object mapper with subobjects=false?

@ywelsch
Copy link
Contributor Author

ywelsch commented Sep 23, 2022

Maybe worth adding a test to check that this doesn't trip when we have a multiple-dotted field name underneath an object mapper with subobjects=false?

It trips this check (while it does not trip the field limit layer when the mapping is validated on the master. I'm not sure why though.). Not sure if this is a dealbreaker or not. @javanna thoughts?

EDIT: found out why this does not trigger on the master (there we only check objectmappers). Still, the problem remains that we can't detect in addDynamicMapper what the nature of the mapper is (subobjects:true or false in the parent)

@ywelsch
Copy link
Contributor Author

ywelsch commented Sep 23, 2022

OK, figured it out now, pushing a fix.

@ywelsch ywelsch requested a review from romseygeek September 23, 2022 14:37
Copy link
Contributor

@romseygeek romseygeek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, one suggested change but good otherwise. No need for a further review.

@ywelsch ywelsch merged commit dae717a into elastic:main Sep 26, 2022
@ywelsch
Copy link
Contributor Author

ywelsch commented Sep 26, 2022

Thanks @romseygeek!

mayya-sharipova added a commit to mayya-sharipova/elasticsearch that referenced this pull request May 1, 2023
Parsing a hugely nested mapping can lead to stack overflow errors.
This PR introduces a protection against this by tracking the depth level
while parsing a object in the mapping, and throwing an error if the max depth
level is exceeded.

Currently we do have a protection against super deep object introduced
in elastic#90285. But this protection is happening during dynamic mapping
update, when the mapping is already parsed. To avoid stack overflow
during parsing, we need this change as well.

Closes elastic#52098
mayya-sharipova added a commit that referenced this pull request May 24, 2023
Parsing a hugely nested mapping can lead to stack overflow errors.
This PR introduces a protection against this by tracking the depth level
while parsing a object in the mapping, and throwing an error if the max depth
level is exceeded. To do this, we use a new mappingParserContext object
to parse every new mapping, and not reuse the same mappingParserContext.

Currently we do have a protection against super deep object introduced
in #90285. But this protection is happening during dynamic mapping
update, when the mapping is already parsed. To avoid stack overflow
during parsing, we need this change as well.

Closes #52098
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>non-issue :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Meta label for search team v8.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants