Bug in has_parent query or faulty index? Getting nested: NullPointerException

The Query + Exception
I started getting the following exception while running queries using
has_parent that previously worked fine:

[2014-07-10 15:16:08,079][DEBUG][action.search.type ] [Needle]
[current][10], node[c2yfYLCPRfOjw_fdEMeAdw], [P
], s[STARTED]: Failed to execute
[org.elasticsearch.action.search.SearchRequest@3d6c0d49]
org.elasticsearch.search.SearchParseException: [current][10]:
from[-1],size[-1]: Parse Failure [Failed to parse sour
ce [{
"query": {
"has_parent": {
"query": {
"match_all": {}
},
"parent_type": "device:1"
}
}
}
]]
at
org.elasticsearch.search.SearchService.parseSource(SearchService.java:649)
at
org.elasticsearch.search.SearchService.createContext(SearchService.java:511)
at
org.elasticsearch.search.SearchService.createAndPutContext(SearchService.java:483)
at
org.elasticsearch.search.SearchService.executeFetchPhase(SearchService.java:324)
at
org.elasticsearch.search.action.SearchServiceTransportAction$11.call(SearchServiceTransportAction.java:308)
at
org.elasticsearch.search.action.SearchServiceTransportAction$11.call(SearchServiceTransportAction.java:305)
at
org.elasticsearch.search.action.SearchServiceTransportAction$23.run(SearchServiceTransportAction.java:517)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.NullPointerException

This is the query, which has been modified to match_all for testing
purposes:

curl -XPOST
"http://elasticsearch-dev-2:9200/current/session:1/_search?routing=1" -d '
{
"query": {
"has_parent": {
"query": {
"match_all": {}
},
"parent_type": "device:1"
}
}
}'

These are the mappings for the two types involved (properties omitted):

{
"device:1": {
"_id": {
"store": true,
"index": "not_analyzed"
},
"_parent": {
"type": "person:1"
},
"_routing": {
"required": true
}
},
"session:1": {
"_id": {
"store": true,
"index": "not_analyzed"
},
"_parent": {
"type": "device:1"
},
"_routing": {
"required": true
}
}
}

The response I get is:

{"error":"SearchPhaseExecutionException[Failed to execute phase
[query_fetch], all shards failed; shardFailures
{[c2yfYLCPRfOjw_fdEMeAdw][current][10]: SearchParseException[[current][10]:
from[-1],size[-1]: Parse Failure [Failed to parse source [\n{\n "query":
{\n "has_parent": {\n "query": {\n "match_all": {}\n
},\n "parent_type": "device:1"\n }\n }\n}]]]; nested:
NullPointerException; }]","status":400}

Interestingly, queries against the parent type using has_child query on the
child type still work without issue.

The indices + cluster
I have 4 nodes in a non-production cluster I'm using for testing
ElasticSearch. All nodes run 1.2.1.

This query was run against the index named 'current', which has 12 shards,
3 shards allocated to each node. 'current' has ~195 million documents
totalling ~47GB.

Running the exact same query on a new index with the exact same mappings
works
Since I'm sure the mappings correctly define their parents, and that this
kind of query used to work, I decided to try the same setup on a new index.

I changed the index name in my application so it creates a new index and
starts afresh with the same mappings. This new index is called 'foo'.

Sure enough, the query works when run against 'foo':

curl -XPOST
"http://elasticsearch-dev-2:9200/foo/session:1/_search?routing=1" -d '
{
"query": {
"has_parent": {
"query": {
"match_all": {}
},
"parent_type": "device:1"
}
}
}'
{"took":4,"timed_out":false,"_shards":{"total":1,"successful":1,"failed":0},"hits":{"total":758,"max_score":1.0
....

The mappings are the same as the 'current' index. The only difference I can
see here is that 'foo' is brand new and has a minute number of documents in
comparison to 'current'.

Is this a bug?
To be fair, I've been doing lots of testing on 'current', and it's been
through the wars in the process (e.g. full cluster-restarts, had to
manually re-allocate some shards, etc.) so it's possible that something's
gone operationally wrong with that. But in any case I don't think this
should be returning a 400 Parse exception to the client if the query and
mappings are in fact legal.

Some additional information
curl -XGET 'http://localhost:9200/_cat/nodes?v'
host ip heap.percent ram.percent load node.role
master name
elasticsearch-dev-4 127.0.0.1 41 39 0.29 d m
War Eagle
elasticsearch-dev-1 127.0.0.1 27 31 0.00 d m
Prototype
elasticsearch-dev-2 127.0.0.1 16 16 0.22 d m
Needle
elasticsearch-dev-3 127.0.0.1 63 33 0.02 d *
Lee Forrester

curl -XGET 'http://localhost:9200/_cat/shards?v'
index shard prirep state docs store ip node
current 3 p STARTED 0 123b 127.0.0.1 Prototype
current 10 p STARTED 3921659 1.6gb 127.0.0.1 Needle
current 6 p STARTED 42188626 13.1gb 127.0.0.1 Needle
current 2 p STARTED 39155398 9.7gb 127.0.0.1 Needle
current 1 p STARTED 0 123b 127.0.0.1 War Eagle
current 0 p STARTED 96165475 19.4gb 127.0.0.1 Lee Forrester
current 7 p STARTED 163592 49.4mb 127.0.0.1 Prototype
current 11 p STARTED 4464981 1.1gb 127.0.0.1 Prototype
current 9 p STARTED 2500764 657.5mb 127.0.0.1 War Eagle
current 5 p STARTED 3494532 852mb 127.0.0.1 War Eagle
current 4 p STARTED 2082070 485.1mb 127.0.0.1 Lee Forrester
current 8 p STARTED 773185 243.2mb 127.0.0.1 Lee Forrester
foo 3 p STARTED 702 522.1kb 127.0.0.1 Prototype
foo 10 p STARTED 12385 10.9mb 127.0.0.1 War Eagle
foo 6 p STARTED 64572 21.9mb 127.0.0.1 War Eagle
foo 2 p STARTED 47905 26mb 127.0.0.1 War Eagle
foo 1 p STARTED 741 652.4kb 127.0.0.1 Needle
foo 0 p STARTED 123643 31.6mb 127.0.0.1 Lee Forrester
foo 7 p STARTED 221 211.7kb 127.0.0.1 Prototype
foo 11 p STARTED 6814 3.6mb 127.0.0.1 Prototype
foo 9 p STARTED 4309 2.5mb 127.0.0.1 Needle
foo 5 p STARTED 4893 2.6mb 127.0.0.1 Needle
foo 4 p STARTED 5915 2.9mb 127.0.0.1 Lee Forrester
foo 8 p STARTED 1528 1.2mb 127.0.0.1 Lee Forrester

--
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/e7305622-2d20-4c0f-a9c8-9e8ef4c43981%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.