Description

Atm, if an ES|QL query targets an index that exists and a concrete index that doesn't, ie from test, inexistent an index_not_found_exception is thrown and reported back to the user at search time (after mappings discovery, analysis, optimization, planning happens).

However, when the query changes to from test, inexistent | limit 0, the optimization rule SkipQueryOnLimitZero will shortcut the execution and the search step is not performed and the query succeeds returning 0 rows.

Aiming to have a consistent behavior is not trivial because the mappings discovery step (using one _field_caps API call) doesn't have the capability to report the missing index. Some research is needed to investigate how this step can be improved and if it's feasible to do so:

• by having a second _field_caps call that will use ignore_unavailable=false. This should be a very light weight call (no fields reported back).
• by maybe using the exists API, but this has some particularities of its own: currently ES|QL does not report "index not found errors" on wildcard index patterns (some_index_or_alias_name* for example) unless the entire list of patterns in the from command doesn't have a match.