# Query string search with \`allow\_leading\_wildcard\` set to false does not throws

**URL:** <https://discuss.elastic.co/t/query-string-search-with-allow-leading-wildcard-set-to-false-does-not-throws/365564>\
**Category:** Elasticsearch\
**Created:** [August 26, 2024, 4:11pm UTC](https://discuss.elastic.co/t/query-string-search-with-allow-leading-wildcard-set-to-false-does-not-throws/365564 "2024-08-26T16:11:55Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![darshan\_v](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/darshan_v/32/137069_2.png) [@darshan\_v](https://discuss.elastic.co/u/darshan_v)\
**Post date:** [August 26, 2024, 4:11pm UTC](https://discuss.elastic.co/t/query-string-search-with-allow-leading-wildcard-set-to-false-does-not-throws/365564/1 "2024-08-26T16:11:55Z")

</div>

Hey! I was testing some `query_string` search queries on Elasticsearch 8.14.0 where I had set `allow_leading_wildcard` to false but the actual query contained a leading wildcard. Instead of throwing an exception, ES returns a http 200 response with shard failure in the response. This is the query I'm using:

```auto
GET /my-index/_search
{
	"_source": true,
	"query": {
		"query_string": {
			"allow_leading_wildcard": false,
			"query": "*orange"
		}
	}
}

```

Response from the query:

```auto
{
	"took": 6,
	"timed_out": false,
	"_shards": {
		"total": 3,
		"successful": 2,
		"skipped": 0,
		"failed": 1,
		"failures": [
			{
				"shard": 1,
				"index": "my-index",
				"node": "{node_id}",
				"reason": {
					"type": "query_shard_exception",
					"reason": "Failed to parse query [*orange]",
					"index_uuid": "{index_uuid}",
					"index": "my-index",
					"caused_by": {
						"type": "parse_exception",
						"reason": "Cannot parse '*orange': '*' or '?' not allowed as first character in WildcardQuery",
						"caused_by": {
							"type": "parse_exception",
							"reason": "'*' or '?' not allowed as first character in WildcardQuery"
						}
					}
				}
			}
		]
	},
	"hits": {
		"total": {
			"value": 0,
			"relation": "eq"
		},
		"max_score": null,
		"hits": []
	}
}

```

Index settings:

```auto
PUT /my-index
{
	"settings": {
		"number_of_shards": 3
	},
	"mappings": {
		"properties": {
			"someContent": {
				"type": "keyword"
			}
		}
	}
}

```

Populating the index:

```auto
POST /_bulk
{ "index" : { "_index" : "my-index", "routing": "parent"} }
{"someContent": "orange"}
{ "index" : { "_index" : "my-index", "routing": "parent"} }
{"someContent": "apple"}
{ "index" : { "_index" : "my-index", "routing": "parent"} }
{"someContent": "bigorange"}
{ "index" : { "_index" : "my-index", "routing": "parent"} }
{"someContent": "smallorange"}

```

The other weird behavior I noticed was that if I set the shard count to 1, ES actually throws the expected exception:

```auto
{
	"error": {
		"root_cause": [
			{
				"type": "parse_exception",
				"reason": "parse_exception: '*' or '?' not allowed as first character in WildcardQuery"
			}
		],
		"type": "search_phase_execution_exception",
		"reason": "all shards failed",
		"phase": "query",
		"grouped": true,
		"failed_shards": [
			{
				"shard": 0,
				"index": "my-index",
				"node": "{node_id}",
				"reason": {
					"type": "query_shard_exception",
					"reason": "Failed to parse query [*orange]",
					"index_uuid": "{index_uuid}",
					"index": "my-index",
					"caused_by": {
						"type": "parse_exception",
						"reason": "parse_exception: Cannot parse '*orange': '*' or '?' not allowed as first character in WildcardQuery",
						"caused_by": {
							"type": "parse_exception",
							"reason": "parse_exception: '*' or '?' not allowed as first character in WildcardQuery"
						}
					}
				}
			}
		],
		"caused_by": {
			"type": "parse_exception",
			"reason": "parse_exception: '*' or '?' not allowed as first character in WildcardQuery"
		}
	},
	"status": 400
}

```

and if I do not populate the index, the search response is returned back without any errors (http 200 OK response) and no shard failures.

This is a bit different from the behavior in Elasticsearch 6 where it would respond back with the exception and http 400 response no matter if the index is populated/the index is split into more than 1 shard.
