Java RestHighLevelClient throws ParsingException if scroll response contains suggests

[xiyangliu]

Elasticsearch version (bin/elasticsearch --version):
5.6.8

Plugins installed: []
analysis-icu
analysis-kuromoji
analysis-smartcn

JVM version (java -version):
1.8.0_73

OS version (uname -a if on a Unix-like system):
macOS High Sierra version10.13.3

Description of the problem including expected versus actual behavior:
Initial search response contains both aggregations and suggests. Following scroll response does not have aggregations but still has suggests. Java RestHighLevelClient raises ParsingException when parsing suggests part from scroll response.

Caused by: java.io.IOException: Unable to parse response body for Response{requestLine=GET /_search/scroll HTTP/1.1, host=http://localhost:9202, response=HTTP/1.1 200 OK}
	at org.elasticsearch.client.RestHighLevelClient.performRequest(RestHighLevelClient.java:415)
	at org.elasticsearch.client.RestHighLevelClient.performRequestAndParseEntity(RestHighLevelClient.java:382)
	at org.elasticsearch.client.RestHighLevelClient.searchScroll(RestHighLevelClient.java:342)
	... 164 common frames omitted
Caused by: org.elasticsearch.common.ParsingException: Could not parse suggestion keyed as [did_you_mean_term]
	at org.elasticsearch.search.suggest.Suggest.fromXContent(Suggest.java:200)
	at org.elasticsearch.action.search.SearchResponse.fromXContent(SearchResponse.java:275)
	at org.elasticsearch.client.RestHighLevelClient.parseEntity(RestHighLevelClient.java:526)
	at org.elasticsearch.client.RestHighLevelClient.lambda$performRequestAndParseEntity$2(RestHighLevelClient.java:382)
	at org.elasticsearch.client.RestHighLevelClient.performRequest(RestHighLevelClient.java:413)
	... 167 common frames omitted

Steps to reproduce:

1. Create an index and a type
2. Ingest data
3. Use Java RestHighLevelClient to perform a SearchRequest which has suggest and starts a scroll context.
4. Use Java RestHighLevelClient to perform a SearchScrollRequest with scroll id returned from step 3.

Provide logs (if relevant):
No related log

[nik9000]

Pinging @elastic/es-core-infra, more specifically @javanna.

[javanna]

The problem here is that the returned suggestion is not keyed by its type, it should be term#did_you_mean_term rather than did_you_mean_term. That is because the high-level client must set the typed_keys parameter to true in order to be able to parse aggs and suggest responses into their own proper object which depend on the returned type.

Unfortunately, the client doesn't set such param when calling searchScroll but only when calling search and multiSearch, and the reason for that is that Elasticsearch itself doesn't support the typed_keys param in its _search/scroll endpoint.

I wonder though why the search scroll endpoint return suggestions? It doesn't return aggregations, why would it return suggestions? That sounds like a bug to me, thoughts @elastic/es-search-aggs ?

@xiyangliu what is the usecase for having suggestions returned as part of a search/scroll response? I think as a workaround, while we figure this out I would take out the suggestion from the initial search request.

[xiyangliu]

@javanna We ask for aggregations and suggestions in the initial search request. They can be parsed successfully from search response.

However in following scroll response, aggregations are removed intentionally (this is mentioned in doc) but suggestions are retained. That's where the parsing exception happens.

I guess the team is aware of the typed_keys issue so they removed aggregations but forget suggestions. Because aggregations also requires a type#name parsing format.

[xiyangliu]

As a work around, we are now using low level client for scroll request and handling scroll response by ourselves.

[javanna]

I am aware of where the problem is, I just don't get why suggestions would be useful in a scroll response, would you have an answer to that? We didn't expect them to be there when building the client, that is why we are not providing the typed_keys parameter. Aggregations were not removed for that reason.

Using the low-level client is quite a drastic work-around, you could just have two search requests, one for the suggestion, and another one without the suggestion to initiate the scroll.

[edudar]

@javanna We use low-level client anyway for APIs that not yet implemented in high-level one (as of v5.6.8) so for us, it's not that drastic, more like a business as usual. An edge case here, however, is that we have a use for aggregations and suggesters on initial search request that creates a scroll. It's UI thing. And no, we don't need either of them when actual scroll request happens subsequently, that's why we manually remove suggest part from json response before feeding it to XContentHelper.createParser()

[jimczi]

We discussed this in FixIt Friday and decided that suggestions should not be part of a scroll request.
You can use multi-search to build two queries, one for suggestion and one for the scroll and then proceed the scroll with the scroll_id returned in the second request.

[javanna]

I think we should do something about this though: be consistent with aggregations that are not being returned as part of scroll responses, hence stop returning suggestions too.

[jpountz]

For the record, we also said we'd like to stop allowing aggregations on the first scroll page, and instead allow users to acquire point-in-time snapshots so that they can run multiple queries against a consistent view of the index, which is the only point of allowing to run aggs and scroll on the same request today: #26472.