Odd Terms Filter Caching Issue

(Justin Treher) #1

First question post-ElasticSearch training! Using v.90.3. I know this is
one of those long specific questions that rarely gets answers, but it is
worth a shot.

What I'm seeing is some sort of bad caching of the terms filter using
bitsets. It's even that one node might return the correct result while the
other doesn't. I did a fresh index this morning and immediately started
getting errors from the application due to data disagreement. I even
deleted the type, recreated, and reimported the data. We use an alias to
manage index switches. Unfortunately, I cannot reproduce this with a full
gist. A simple example doesn't seem to have the issue and it seems to be


"id": {
"type": "integer",
"analyzer": "keyword",


,"name":"blue pegs"

,"name":"half sized blue pegs"

,"name":"orange pegs"

query terms filter like so:

{"filter": {
"terms": {
"id": [

What I will get back for terms [343,501]
343,353 <- wrong!

If I set cache:false or "execution":"bool" I will get the correct response
of [343,501]

What I get back for terms: [343]
343 <- correct

What I get back for terms: [501]
501 <- correct

What I get back for terms: [353]
353 <- correct

What I get back for terms: [353,343]
353,343 <-correct!

There is something very funny going on here.

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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3904b3c7-142d-48f3-a5df-41ef1d0aace3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

(system) #2