# Bug in has\_parent query or faulty index? Getting nested: NullPointerException **URL:** \ **Category:** Elasticsearch\ **Created:** [July 10, 2014, 3:44pm UTC](https://discuss.elastic.co/t/bug-in-has-parent-query-or-faulty-index-getting-nested-nullpointerexception/18579 "2014-07-10T15:44:09Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![TheDeveloper](https://avatars.discourse-cdn.com/v4/letter/t/439d5e/32.png) [@TheDeveloper](https://discuss.elastic.co/u/TheDeveloper)\ **Post date:** [July 10, 2014, 3:44pm UTC](https://discuss.elastic.co/t/bug-in-has-parent-query-or-faulty-index-getting-nested-nullpointerexception/18579/1 "2014-07-10T15:44:09Z")
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](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](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](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](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](mailto: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](https://groups.google.com/d/msgid/elasticsearch/e7305622-2d20-4c0f-a9c8-9e8ef4c43981%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:16am UTC](https://discuss.elastic.co/t/bug-in-has-parent-query-or-faulty-index-getting-nested-nullpointerexception/18579/2 "2017-07-06T01:16:46Z")