-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Correctly handle non-integers in nested paths in the remove processor #127006
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
Correctly handle non-integers in nested paths in the remove processor #127006
Conversation
If we don't throw, then the index wouldn't have been initialized, so now it's declared as being -1 -- note that this means that in the event of a non-integer it'll fall through to the next block with `if (index < 0` and that that one also won't throw. This seemed simpler to me than adding in an early return.
Pinging @elastic/es-data-management (Team:Data Management) |
Hi @joegallo, I've created a changelog YAML for you. |
@parkertimmins after you've finished reviewing this on its own terms, but before you add a ✅, let's step through the |
Related to elastic/integrations#13455 and elastic/integrations#13294 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
💚 Backport successful
|
Fixes a bug that was introduced by #125232.
During path traversal, if we find a non-integer path for the next access inside a list, then that doesn't necessarily mean we must throw an exception -- rather, we should only throw an exception on a non-integer if ignoreMissing is false. That is, we should treat accessing the
"foo"
index inside a list as just another missing path (for example).See also #126417 which is similar to this, but not the same. 😬