Currently EQL requires at least one index to match in order to validate the query. However just like search, the allow_no_indices option is permitted which leads to confusing behavior since it can be true, yet EQL will throw an exception:
### A
GET foo*/_search
# success
GET foo*/_eql/search
{
"size": 0,
"query": "process where 1 == 1"
}
# "type" : "index_not_found_exception",
# "reason" : "no such index [foo*]",
### B
GET foo/_search?ignore_unavailable=true
# success
GET foo/_eql/search?ignore_unavailable=true
{
"size": 0,
"query": "process where 1 == 1"
}
# "type" : "index_not_found_exception",
# "reason" : "no such index [[foo]]",
### C
GET foo/_search
# "type" : "index_not_found_exception",
# "reason" : "no such index [foo]",
GET foo/_eql/search
{
"size": 0,
"query": "process where 1 == 1"
}
# "type" : "mapping_exception",
# "reason" : "Unknown index [foo]",
### D
GET foo*/_search?allow_no_indices=false
# "type" : "index_not_found_exception",
# "reason" : "no such index [foo*]",
GET foo*/_eql/search?allow_no_indices=false
{
"size": 0,
"query": "process where 1 == 1"
}
# "type" : "index_not_found_exception",
# "reason" : "no such index [foo*]",
GET foo*/_eql/search?allow_no_indices=true
{
"size": 0,
"query": "process where 1 == 1"
}
# "type" : "mapping_exception",
# "reason" : "Unknown index [*,-*]"
Considering the similarities to the search API, EQL should either provide a similar behavior or not accept this parameter.
Currently EQL requires at least one index to match in order to validate the query. However just like search, the
allow_no_indicesoption is permitted which leads to confusing behavior since it can be true, yet EQL will throw an exception:Considering the similarities to the search API, EQL should either provide a similar behavior or not accept this parameter.