-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Bug fix: Facilitate second retrieval of the same value (#134770) #134790
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
Bug fix: Facilitate second retrieval of the same value (#134770) #134790
Conversation
Pinging @elastic/es-core-infra (Team:Core/Infra) |
Hi @gmarouli, I've created a changelog YAML for you. |
...impl/src/test/java/org/elasticsearch/xcontent/provider/json/ESUTF8StreamJsonParserTests.java
Outdated
Show resolved
Hide resolved
- match: | ||
hits.hits.0._source.foo: "c:\\windows\\system32\\svchost.exe" | ||
|
||
- do: |
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.
If possible, I'd add a comment here pointing to the bug issue, so it's immediately clear why we are calling this twice (a future dev might be tempted to "clean up" things and remove the second call)
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.
One Q and one idea to increase test coverage but LGTM
var text = parser.getValueAsText(); | ||
assertThat(text, Matchers.notNullValue()); | ||
assertTextRef(text.bytes(), "bar\"baz\""); | ||
// Retrieve the value for a second time to ensure the last value is available |
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.
Would make it sense to test the reset of the lastOptimizedValue too? e.g. calling nextFieldName/nextToken + getValueAsText and ensure the content is not stale?
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.
Good catch, thanks for fixing this Mary! I had one suggestion for testing, but overall LGTM!
// Retrieve the value for a second time to ensure the last value is available | ||
text = parser.getValueAsText(); | ||
assertThat(text, Matchers.notNullValue()); | ||
assertTextRef(text.bytes(), "bar\"baz\""); |
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.
You might consider updating testGetValueRandomized()
to also double-retrieve the value from the parser.
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, thanks Mary for fixing this!
💔 Backport failed
You can use sqren/backport to manually backport by running |
… (elastic#134790) In this PR we attempt to fix elastic#134770, we have identified the issue at the retrieval of the field value for the second time in order to populate the keyword multi-field. We noticed that when the we performed the second retrieval it was not using the recently optimised value, but the value of the initial buffer. We added a new variable that "remembers" the optimised value and allows us to reuse it.
…lue. (#135184) In #134790 we introduced a bug that was caught by our tests.; The problem manifested itself when a multi field mapper would call `getText()` which would set `_tokenIncomplete` to `false` after the `getOptimisedText()`. This would evaluate the condition `_currToken == JsonToken.VALUE_STRING && _tokenIncomplete && stringEnd > 0` to false and the `lastOptimisedValue` would not be reset. We changed the code to always reset the `lastOptimisedValue` when a `next*()` method is called. Furthermore, we introduced a randomised unit test that creates two `XContentParsers` and runs one as a baseline using none of the optimised code and the other one is accessing both optimised and non optimised in a random pattern. This test was able to catch both #134770 & #135256. Fixes #135256
In this PR we attempt to fix #134770, we have identified the issue at the retrieval of the field value for the second time in order to populate the keyword multi-field.
We noticed that when the we performed the second retrieval it was not using the recently optimised value, but the value of the initial buffer. We added a new variable that "remembers" the optimised value and allows us to reuse it.