I'm currently using the InnerHits API (In Java) to return some child documents, and it appears that the documents being returned fail to have a shard set on the SearchHit (Not the Inner document SearchHits, but the document type being returned).
The first SearchHit returned on the SearchResponse has a shard set on it, with all further SearchHits having the shard set to null. This only occurs if the search that was constructed has InnerHits set.
I've gone through release notes and have been unable to find any reference to this change.
Going through the ElasticSearch source briefly makes me think this is a bug in the InternalSearchHit class in the readFrom function (line 556) as the ShardTargetType is set to NO_STREAM when the first set of InnerHits are processed, with this causing the subsequent non-InnerHits to not set the shard.
Can anyone confirm if this is indeed a bug, or if it is intended?
I've added a basic test program below which reproduces this.
The Parent and Child documents are very basic, both having just a simple Title text field, with the child document having the parent set as the parent (routing etc. is all configured correctly).
As you can see, the second document returns a null shard value when an inner hit is being used in the search. I could understand if it was the inner hit that didn't have a shard set, however this is a document of the result type, which has a shard set if inner hits aren't used (the size of the result doesn't make a difference, the shard is only ever being set on the first document in the SearchHits).
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.