The semantics of "_refresh" is to execute a Lucene "maybeRefresh" with a force attribute. This might also affect ES ID cache access that is not part of the Lucene refresh operation.
There is an extra clear ID cache API beside refresh API, so that ES ID cache can be cleared by another API request. For convenience, it could be more comprehensible to include a clear ID cache operation into each refresh API request. On the other hand, invalidating caches can be expensive, so there are two API calls for good reason. So, it is a kind of interpretation what can be expected from a refresh API call. I would call it a glitch, and it seems specific to parent/child. My rule of thumb: if you have a parent/child query on docs you created between different API forced refresh calls, call the clear ID cache API, so for the parent/child query, a valid ID cache will get populated again. Maybe you should open an issue to get this tracked by the ES team, because the current behavior is not corresponding to a "least surprise" principle. Jörg -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFY4Dcd4hXzsf8k-vWZkpn7EsPTxhHxk-hTNK_gUiq4Jg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
