Prevent field caps from failing due to can match failure #134134
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dimitris-athanasiou
added
>bug
auto-backport
elasticsearchmachine
added
the
Team:Search Relevance
|
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
|
Note: The first commit is reverting #131111. Before merging I'll split that out of this PR and raise it separately. But it is necessary for the fix to be reviewed here. |
Mikep86
reviewed
Sep 4, 2025
server/src/main/java/org/elasticsearch/action/fieldcaps/FieldCapabilitiesFetcher.java
Show resolved
Hide resolved
...nference/src/main/java/org/elasticsearch/xpack/inference/mapper/SemanticTextFieldMapper.java
Outdated
Show resolved
Hide resolved
...nce/src/yamlRestTest/resources/rest-api-spec/test/inference/100_semantic_text_field_caps.yml
Outdated
Show resolved
Hide resolved
...nce/src/yamlRestTest/resources/rest-api-spec/test/inference/100_semantic_text_field_caps.yml
Outdated
Show resolved
Hide resolved
...nce/src/yamlRestTest/resources/rest-api-spec/test/inference/100_semantic_text_field_caps.yml
Outdated
Show resolved
Hide resolved
dimitris-athanasiou
force-pushed
the
prevent-field-caps-from-failing-due-to-can-match-failure
branch
from
d9e9315 to
3e5e34d
Compare
|
run elasticsearch-ci/part-2 |
|
@Mikep86 I have addressed review comments. This is ready for another look. |
Mikep86
reviewed
Sep 9, 2025
There was a problem hiding this comment.
Looks good except for two things:
- A missing cluster feature check
- No changelog entry for the bug fix. CI should catch this, but maybe that's broken because we are reverting another changelog entry in this PR. Can you manually add it?
Once those are fixed, there are some logistics about how to merge and backport this:
- Merge #134209 first and merge those changes into this PR, which should cancel out the revert changes here.
- Merge and backport this, which should go smoothly now that the revert changes above are cancelled out.
...e/src/yamlRestTest/resources/rest-api-spec/test/inference/10_semantic_text_field_mapping.yml
Show resolved
Hide resolved
...c/yamlRestTest/resources/rest-api-spec/test/inference/10_semantic_text_field_mapping_bwc.yml
Show resolved
Hide resolved
|
@Mikep86 I have added the missing cluster feature checks and the changelog. I'm also fully onboard with the merging plan you laid out. |
`FieldCapabilitiesFetcher` performs a can-match in order to quickly return an empty response if no shard can match. However, if can-match fails for some reason, it can cause the field capabilities request to fail. An example of that is when a semantic query is used as filter. can-match will fail as it won't be able to expand the inference results of the query. In cases like that, it makes no sense to fail the field capabilities request. Instead, we should treat can-match as returning `true` to proceed. This change does that by following suit with other callers of can-match. Fixes elastic#116106
dimitris-athanasiou
force-pushed
the
prevent-field-caps-from-failing-due-to-can-match-failure
branch
from
fb31c64 to
933bf28
Compare
|
@elasticsearchmachine run elasticsearch-ci/part-1 |
|
@elasticmachine run elasticsearch-ci/part-3 |
dimitris-athanasiou
added a commit
to dimitris-athanasiou/elasticsearch
that referenced
this pull request
Sep 11, 2025
) `FieldCapabilitiesFetcher` performs a can-match in order to quickly return an empty response if no shard can match. However, if can-match fails for some reason, it can cause the field capabilities request to fail. An example of that is when a semantic query is used as filter. can-match will fail as it won't be able to expand the inference results of the query. In cases like that, it makes no sense to fail the field capabilities request. Instead, we should treat can-match as returning `true` to proceed. This change does that by following suit with other callers of can-match. Fixes elastic#116106 (cherry picked from commit 7295189) # Conflicts: # x-pack/plugin/inference/src/main/java/org/elasticsearch/xpack/inference/InferenceFeatures.java # x-pack/plugin/inference/src/main/java/org/elasticsearch/xpack/inference/queries/SemanticQueryBuilder.java
dimitris-athanasiou
added a commit
to dimitris-athanasiou/elasticsearch
that referenced
this pull request
Sep 11, 2025
) `FieldCapabilitiesFetcher` performs a can-match in order to quickly return an empty response if no shard can match. However, if can-match fails for some reason, it can cause the field capabilities request to fail. An example of that is when a semantic query is used as filter. can-match will fail as it won't be able to expand the inference results of the query. In cases like that, it makes no sense to fail the field capabilities request. Instead, we should treat can-match as returning `true` to proceed. This change does that by following suit with other callers of can-match. Fixes elastic#116106 (cherry picked from commit 7295189) # Conflicts: # x-pack/plugin/inference/src/main/java/org/elasticsearch/xpack/inference/InferenceFeatures.java # x-pack/plugin/inference/src/main/java/org/elasticsearch/xpack/inference/queries/SemanticQueryBuilder.java # x-pack/plugin/inference/src/yamlRestTest/resources/rest-api-spec/test/inference/10_semantic_text_field_mapping.yml # x-pack/plugin/inference/src/yamlRestTest/resources/rest-api-spec/test/inference/10_semantic_text_field_mapping_bwc.yml
This was referenced Sep 11, 2025
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
dimitris-athanasiou
added a commit
to dimitris-athanasiou/elasticsearch
that referenced
this pull request
Sep 11, 2025
) `FieldCapabilitiesFetcher` performs a can-match in order to quickly return an empty response if no shard can match. However, if can-match fails for some reason, it can cause the field capabilities request to fail. An example of that is when a semantic query is used as filter. can-match will fail as it won't be able to expand the inference results of the query. In cases like that, it makes no sense to fail the field capabilities request. Instead, we should treat can-match as returning `true` to proceed. This change does that by following suit with other callers of can-match. Fixes elastic#116106 (cherry picked from commit 7295189) # Conflicts: # x-pack/plugin/inference/src/main/java/org/elasticsearch/xpack/inference/InferenceFeatures.java # x-pack/plugin/inference/src/main/java/org/elasticsearch/xpack/inference/queries/SemanticQueryBuilder.java # x-pack/plugin/inference/src/yamlRestTest/resources/rest-api-spec/test/inference/10_semantic_text_field_mapping.yml # x-pack/plugin/inference/src/yamlRestTest/resources/rest-api-spec/test/inference/10_semantic_text_field_mapping_bwc.yml
dimitris-athanasiou
added a commit
that referenced
this pull request
Sep 11, 2025
…134551) `FieldCapabilitiesFetcher` performs a can-match in order to quickly return an empty response if no shard can match. However, if can-match fails for some reason, it can cause the field capabilities request to fail. An example of that is when a semantic query is used as filter. can-match will fail as it won't be able to expand the inference results of the query. In cases like that, it makes no sense to fail the field capabilities request. Instead, we should treat can-match as returning `true` to proceed. This change does that by following suit with other callers of can-match. Fixes #116106 (cherry picked from commit 7295189)
dimitris-athanasiou
added a commit
that referenced
this pull request
Sep 11, 2025
…) (#134552) `FieldCapabilitiesFetcher` performs a can-match in order to quickly return an empty response if no shard can match. However, if can-match fails for some reason, it can cause the field capabilities request to fail. An example of that is when a semantic query is used as filter. can-match will fail as it won't be able to expand the inference results of the query. In cases like that, it makes no sense to fail the field capabilities request. Instead, we should treat can-match as returning `true` to proceed. This change does that by following suit with other callers of can-match. Fixes #116106 (cherry picked from commit 7295189)
dimitris-athanasiou
added a commit
that referenced
this pull request
Sep 11, 2025
) (#134558) `FieldCapabilitiesFetcher` performs a can-match in order to quickly return an empty response if no shard can match. However, if can-match fails for some reason, it can cause the field capabilities request to fail. An example of that is when a semantic query is used as filter. can-match will fail as it won't be able to expand the inference results of the query. In cases like that, it makes no sense to fail the field capabilities request. Instead, we should treat can-match as returning `true` to proceed. This change does that by following suit with other callers of can-match. Fixes #116106 (cherry picked from commit 7295189)
dimitris-athanasiou
added a commit
that referenced
this pull request
Sep 11, 2025
) (#134557) `FieldCapabilitiesFetcher` performs a can-match in order to quickly return an empty response if no shard can match. However, if can-match fails for some reason, it can cause the field capabilities request to fail. An example of that is when a semantic query is used as filter. can-match will fail as it won't be able to expand the inference results of the query. In cases like that, it makes no sense to fail the field capabilities request. Instead, we should treat can-match as returning `true` to proceed. This change does that by following suit with other callers of can-match. Fixes #116106 (cherry picked from commit 7295189)
dimitris-athanasiou
deleted the
prevent-field-caps-from-failing-due-to-can-match-failure
branch
sarog
pushed a commit
to portsbuild/elasticsearch
that referenced
this pull request
Sep 19, 2025
…tic#134134) (elastic#134557) `FieldCapabilitiesFetcher` performs a can-match in order to quickly return an empty response if no shard can match. However, if can-match fails for some reason, it can cause the field capabilities request to fail. An example of that is when a semantic query is used as filter. can-match will fail as it won't be able to expand the inference results of the query. In cases like that, it makes no sense to fail the field capabilities request. Instead, we should treat can-match as returning `true` to proceed. This change does that by following suit with other callers of can-match. Fixes elastic#116106 (cherry picked from commit 7295189)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Prevent field_caps from failing when can-match fails
FieldCapabilitiesFetcherperforms a can-match in order to quicklyreturn an empty response if no shard can match. However, if can-match
fails for some reason, it can cause the field capabilities request to fail.
An example of that is when a semantic query is used as filter. can-match
will fail as it won't be able to expand the inference results of the query.
In cases like that, it makes no sense to fail the field capabilities request.
Instead, we should treat can-match as returning
trueto proceed.This change does that by following suit with other callers of can-match.
Fixes #116106