Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ES|QL CCS uses skip_unavailable setting for handling disconnected remote clusters #115266
ES|QL CCS uses skip_unavailable setting for handling disconnected remote clusters #115266
Changes from 21 commits
da778ee
c784ebb
737ca7c
43cf559
6f73b4d
a79a32b
e84e0c8
52ce899
e8626c1
3027b58
21e849c
a7ca28d
2d4bc98
ac1cb85
22871a8
b3956f4
67454fd
e4fa48c
ab24843
1622065
5fbb373
3c95dfe
bb6b96c
06aa298
5fd33f0
59fe3e9
dc122c3
cd56a2e
dc2a75b
bcdaad3
9369d29
4b5c72b
db2a441
8eda8c8
2a4c06c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this.failures = failures == null ? emptyList() : failures
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason why the collection is unmodifiable - within the ESQL code we're not using the defensive style since the collections are never modified, rather copied.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The EsqlExecution.Cluster class, like the SearchResponse.Cluster class it is based on, is immutable. You can only change state by coping an existing Cluster and swapping it in. I can change line 374 to use a mutable list, but it won't make any difference since the coding practice for this class is to never modify in place. In fact, the line below where I do
this.failures = List.of();
should likely be changed to an immutable list as well to enforce this model.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find a test for this situation. Does it make sense to add one now? (I know there are several other follow up PRs in this area)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code was added in response to one of the IT tests I added failing:
CrossClusterEnrichUnavailableClustersIT..testEnrichWithHostsPolicyAndDisconnectedRemotesWithSkipUnavailableTrue, and in particular when the 2nd cluster is taken offline: https://github.com/elastic/elasticsearch/pull/115266/files#diff-67efeda55a8a497d595e7ce7737ee3ae3acc3ec966db031190bd6954a610f88aR240
In that case invariants in the code below are not met and assertion failures are thrown, so I added this to just leave the code immediately when there are no targetClusters, which can happen when the Enrich Mode type is "REMOTE" and the local cluster was not included in the query.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By this point, as I understand, we have already run field caps resolution. So we may have some skipped clusters. Do we exclude them somewhere from the list of clusters for which we're going to resolve policies? Because it looks like it's pointless to try to resolve those policies if the cluster will be skipped anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the enrich policy resolution is done before the field-caps. I'm not sure why or if that's necessary for some reason or just historical accident. IMO, the field-caps call seems the logical one to do first, but that's not how it is, so we need to track unavailable clusters here and then pass that list to the callback listener which is the one that does the field-caps lookup: https://github.com/elastic/elasticsearch/pull/115266/files#diff-40060e2ec9003953a228c4a03bdc80a301949b0d4e3dccc1978798e33a992a73R345
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh ok, I was for some reason assuming field caps go first... then of course yes, enrich should be telling field caps which clusters are skipped, not the other way around.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the code is similar between onFailure and onResponse, pull it out in a separate method.