Skip to content

Conversation

@smalyshev
Copy link
Contributor

In relation to the recent skip_unavailable=true change, there's still an inconsistency there. The change in #128163 covers most runtime errors, however it does not cover one code path, namely the one covered by CssPartialErrorsActionListener.onFailure - which handles failures that happen in analyzedPlan . There the code still has this condition:

        if (e instanceof NoClustersToSearchException || ExceptionsHelper.isRemoteUnavailableException(e)) {

which controls the code path where all remotes that we tried when attempting to resolve index failed, and we're about to return an empty result (we're talking about skip_unavailable=true here).
However, if the error that happened on the remote is not a disconnect error but some other error, unlike the runtime branch, skip_unavailable=true would not cover it, and we would still return a failure.

In addition to that, when other indices are present, the same error would instead be hidden by mergedMappings because it is currently only processes unavailability errors.

@smalyshev smalyshev changed the title Tests demonstrating inconsistencies in error handling when skip_unavailable=true Tests demonstrating ES|QL inconsistencies in error handling when skip_unavailable=true Jul 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants