EQL queries appear to have differing behavior for the ignore_unavailable option as compared to a standard query.
While a user can perform a regular search across unavailable indexes:
# SETUP: indexes match the auditbeat-* pattern, while none matches foo*
GET auditbeat-*,foo*/_search
// success
GET auditbeat-*,foo*/_eql/search
// index_not_found_exception: no such index [foo*]
This only appears to be an issue with wildcard indexes, since passing a concrete (unavailable) index works as expected:
GET auditbeat-*,foo*/_eql/search
// index_not_found_exception: no such index [foo*]
GET auditbeat-*,foo/_eql/search
// success
Update: one more data point: allow_no_indices can be used to bypass this behavior:
GET auditbeat-*,foo*/_eql/search
// index_not_found_exception: no such index [foo*]
GET auditbeat-*,foo*/_eql/search?allow_no_indices=true
// success
Note: this is a followup to this issue, particularly: this comment.
EQL queries appear to have differing behavior for the
ignore_unavailableoption as compared to a standard query.While a user can perform a regular search across unavailable indexes:
This only appears to be an issue with wildcard indexes, since passing a concrete (unavailable) index works as expected:
Update: one more data point:
allow_no_indicescan be used to bypass this behavior:Note: this is a followup to this issue, particularly: this comment.