fix: keep sort in search hit as is #1576
Open
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.
'sort' in search hit should be kept as is.
In some cases, when search documents while sort by an int64 field (date_nano for example), server returns a sort value in each hit, which contains a long number. If we represent sort as []interface{}, the long number will be treated as float64 by std json decoder, and if the number is great enough (and date_nano value of tody is great enough), we will get an incorrect int64 value in go.
And when the incorrect sort value is used for next search reqeuest (set as search_after parameter), we may see duplicated or missing documents in pagingated search requests.
To keep backward compatable, I did not remove or change the type of
Sort
field inSearchHit
, but add a new fieldRawSort
as[]json.RawMessage
and json unmarshaller instread.