You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ESQL: Honor skip_unavailable setting for nonmatching indices errors at planning time (#116348) (#116824)
Adds support to ES|QL planning time (EsqlSession code) for dealing with non-matching indices and
how that relates to the remote cluster skip_unavailable setting and also how to deal with missing
indices on the local cluster (if included in the query).
For clusters included in an ES|QL query:
• `skip_unavailable=true` means:
if no data is returned from that cluster (due to cluster-not-connected, no matching indices, a missing
concrete index or shard failures during searches), it is not a "fatal" error that causes the entire query to fail.
Instead it is just a failure on that particular cluster and partial data should be returned from other clusters.
• `skip_unavailable=false` means:
if no data is returned from that cluster (for the same reasons enumerated above), then the whole query
should fail. This allows users to ensure that data is returned from a "required" cluster.
• For the local cluster, ES|QL assumes `allow_no_indices=true` and the skip_unavailable setting does not apply
(in part because there is no way for a user to set skip_unavailable for the local cluster)
Based on discussions with ES|QL team members, we defined the following rules to be enforced with respect to non-matching index expressions:
**Rules enforced at planning time**
P1. fail the query if there are no matching indices on any cluster (VerificationException)
P2. fail the query if a skip_unavailable:false cluster has no matching indices (the local cluster already has this rule enforced at planning time)
P3. fail query if the local cluster has no matching indices and a concrete index was specified
**Rules enforced at execution time**
For missing concrete (no wildcards present) index expressions:
E1. fail the query when it was specified for the local cluster or a skip_unavailable=false remote cluster
E2: on skip_unavailable=true clusters: an error fails the query on that cluster, but not the entire query
(data from other clusters still returned)
**Notes on the rules**
P1: this already happens, no new code needed in this PR
P2: The reason we need to enforce rule 2 at planning time is that when there are no matching indices from
field caps the EsIndex that is created (and passed into IndexResolution.valid) leaves that cluster out of the
list, so at execution time it will not attempt to query that cluster at all, so execution time will not catch
missing concrete indices. And even if it did get queried at execution time it wouldn't fail on wildcard only
indices where none of them matched.
P3: Right now `FROM remote:existent,nomatch` does NOT throw a failure (for same reason described in rule 2 above)
so that needs to be enforced in this PR.
This PR deals with enforcing and testing the planning time rules: P1, P2 and P3. A follow-on PR will address changes needed for handling the execution time rules.
**Notes on PR scope**
This PR covers nonsecured clusters (`xpack.security.enabled: false`) and security using certs ("RCS1).
In my testing I've founding that api-key based security ("RCS2") is not behaving the same, so that
work has been deferred to a follow-on PR.
Partially addresses #114531
Copy file name to clipboardExpand all lines: x-pack/plugin/esql/src/internalClusterTest/java/org/elasticsearch/xpack/esql/action/CrossClustersQueryIT.java
0 commit comments