Query string with wild card not returning the expected results , all the times

[sngs1 (Ganga C K)]

I am using ES 6.4 .
When I tried
GET /_search?size=10&from=0
{
"_source":["name"],
"query":{
"query_string" : {
"query" : "(some1.some.string.test.query.1234.test) AND (status:active) AND NOT (xyz OR abc)",
"fields" : ["name"]
}
}
}

It is returning expected results.

But when I tried ,
GET /_search?size=10&from=0
{
"_source":["name"],
"query":{
"query_string" : {
"query" : "(some1.some.string.test.query.1234.) AND (status:active) AND NOT (xyz OR abc)",
"fields" : ["name"]
}
}
}

It is returning null, even though matches are there.
{
"took": 38,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 0,
"max_score": null,
"hits":
}
}

Can any of you give me more idea on what happens in this case, when wild card is used along with longer strings?
Thanks in advance.

[MiTschMR]

Hi @sngs1

I think you need to escape the "*" character as follows:

some1.some.string.test.query.1234.\*

I had to do this too with ELK version 6.6.1. Since version 7.x (I dont remember exactly which one) it is no longer necessary to escape.

Hope this helps.

[sngs1 (Ganga C K)]

Thanks for the reply. I have already tried using backslash.
But single backslash is not supported

\*some1.some.string.test.query.1234.\*
"type": "json_parse_exception",
"reason": "Unrecognized character escape '*' (code 42)\n at [Source: org.elasticsearch.transport.netty4.ByteBufStreamInput@55a18add; line: 5, column: 21]"

So I tried
\\*some1.some.string.test.query.1234.\\* with double backslash, and that gave me the expected results.

But the same on a small string (sub string of the same) didn't returned any results.
\\*some1.\\*
{
"took": 1,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 0,
"max_score": null,
"hits":
}
}

[MiTschMR]

Hi @sngs1

Have you tried using the same string in the Kibana search mask?

[sngs1 (Ganga C K)]

No, I will try.
It is also not returning the expected results if we search for some string like
"@xyz.com"