New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
date_histogram w/ extended_bounds fails on alias/index name #19009
Comments
Thanks for the clear recreation. Actually, I'd disagree with the output from @colings86 could you take a look please? |
Hmm, I haven't yet run your recreation @wrobstory (thanks for such a complete explanation/recreation btw) but it looks like the problem here is that the extended bounds information is not sent back to the coordinating node in the shard response if the shard had no matching documents. We arbitrarily pick one of the responses to use as the guide for the reduce phase (this is actually the first in the list and I wouldn't be surprised if the list is in fact sorted by index name first) so if we choose one which matched no documents it won't do the last step of completing the extended bounds (leading to the weird behaviour where the name of the index makes a difference to the result). In theory it should be an easy fix, to send back the extended bounds information as part of the empty aggregation response. I'll look into making this change soon. |
@wrobstory I have raise #19085 to address this issue |
Previous to this change the unresolved extended bounds was passed into the histogram aggregator which meant extendedbounds.min and extendedbounds.max was passed through as null. This had two effects on the histogram aggregator: 1. If the histogram aggregator was unmapped across all shards, the reduce phase would not add buckets for the extended bounds and the response would contain zero buckets 2. If the histogram aggregator was not unmapped in some shards, the reduce phase might sometimes chose to reduce based on the unmapped shard response and therefore the extended bounds would be ignored. This change resolves the extended bounds in the unmapped case and solves the above two issues. Closes #19009
Thanks for the great communication and quick turnaround! Much appreciated! |
Elasticsearch version: 2.3.2
JVM version: 1.7.0_67
OS version: OSX 10.11.4
Description of the problem including expected versus actual behavior:
Start with two indices and an alias for both, the second with a new field introduced:
I want to do a
date_histogram
aggregation over the alias withextended_bounds
. The results for each index individually are what I would expect:However, when using the alias, the
extended_bounds
fail:Here's the tricky part: this behavior depends on the actual index name. Same steps, but a different name for the second index:
The results for each index:
Except this time, the aggregation over the alias works as expected:
The steps to reproduce are above, and I would expect the query against the alias to respect the
extended_bounds
parameter no matter what the index names are.The text was updated successfully, but these errors were encountered: