elastic
Incompatible boolean values in hit.sort and SearchRequest.searchAfter
Java API client version
7.17.1
Java version
17.0
Elasticsearch Version
7.17.1
Problem description
If the search results is ordered by a boolean field, the sort field in hit is returned as number value 0 or 1. However, in the client, it is deserialized into string, thus becomes string value "0" and "1". When passing this value to search_after field in search request, it expects the string value "false" or "true". "0" and "1" are not valid values. Even though number 0 and 1 value works in raw http request, since the new java client does not provide a way to pass in anything other than a string (SearchRequest.searchAfter is a list of string), there is no easy way to do proper pagination unless you know the type of each field.
Suggest either to change on the server side so that it returns "false" or "true" in hit's sort field, or allow both Hit.sort and SearchRequest.searchAfter to take List<JsonValue> instead of just List<String>.
Hi @swallez, Could you please advise whether this is going to be fixed in the nearest future? Thank you!
@visualage We have run into this as well. Assuming we'll have to do a workaround of setting "true" or "false" explicitly when we know the type, which is annoying.
The HLRC dealt with Object[] for the sort keys and search_after, so it was able to sidestep this.
It'd be nice to know this client is getting some attention!
This has been fixed in version 8.5.0 and both fields are now List<FieldValue>. This is has also been fixed in the 7.17 branch but not yet included in a release.
@swallez We are facing the same problem and just updated to the latest 7.17.18 client and server version:
Caused by: org.elasticsearch.ElasticsearchException: Elasticsearch exception [type=illegal_argument_exception, reason=Cannot parse boolean [0], expected either [true] or [false]]
Our mapping looks like this:
....
"enabled" : {
"type" : "boolean"
}
....
The initial response hits, when sorting on the enabled field, contains 0 as an integer. If we pass this sort value in the search_after we experience described error. Do you have any idea if the fix is still not release in 7.x?
This has been fixed in version 8.5.0 and both fields are now
List<FieldValue>. This is has also been fixed in the 7.17 branch but not yet included in a release.
Should getSortValues return List<FieldValue?