-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Non existing synonyms sets do not fail shard recovery #125659
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
Non existing synonyms sets do not fail shard recovery #125659
Conversation
| excludeList.add("cat.shards/10_basic/Help") | ||
|
|
||
| // Can't work until auto-expand replicas is 0-1 for synonyms index | ||
| excludeList.add("synonyms/90_synonyms_reloading_for_synset/Reload analyzers for specific synonym set") |
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 is unrelated to this change, but a good opportunity to enable this test again
rest-api-spec/src/yamlRestTest/resources/rest-api-spec/test/synonyms/110_synonyms_invalid.yml
Show resolved
Hide resolved
| if (ignoreMissing == false) { | ||
| throw e; | ||
| } | ||
| logger.info( |
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.
should this be logger.error instead?
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 thought about that - but I don't think it's something that prevents usage or indicates a problem on Elasticsearch. I think it's similar to having an invalid synonym rule.
On the other hand, duplicate terms in dictionaries are set as WARN.
I'm changing it to WARN, does that sound good?
rest-api-spec/src/yamlRestTest/resources/rest-api-spec/test/synonyms/110_synonyms_invalid.yml
Show resolved
Hide resolved
…existing-synonyms' into bugfix/synonyms-error-non-existing-synonyms
| - match: { hits.total.value: 1 } | ||
|
|
||
| --- | ||
| "Fail loading synonyms from index if synonyms_set doesn't exist": |
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 moved this test to 100_synonyms_invalid
|
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
|
Pinging @elastic/search-eng (Team:SearchOrg) |
|
Pinging @elastic/search-relevance (Team:Search - Relevance) |
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.
Thanks @carlosdelest, I left some comments
| if (ignoreMissing == false) { | ||
| throw e; | ||
| } | ||
| logger.warn( |
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.
Should this be at the error level?
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 also wonder if we should handle all exceptions rather than just the resource not found one?
Maybe we should even retry if that's appropriate (based on the exception)?
I am fine if we do that in a follow up but a comment here would help to understand why we do that.
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.
Should this be at the error level?
I was discussing this with @mayya-sharipova - I think this is not something that prevents ES from working, it's more of a user error. I think WARN is the appropriate level.
I also wonder if we should handle all exceptions rather than just the resource not found one?
That's a good point - Adding that as a log with ERROR level in ecb2f26
Maybe we should even retry if that's appropriate (based on the exception)?
I'm not sure, what errors would benefit from a retry?
Shard allocation already is tried a number of times, so I think we should be covered here. In case it can be fixed after some additional action, reroute can be used to recover the shard.
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.
Shard allocation already is tried a number of times, so I think we should be covered here. In case it can be fixed after some additional action, reroute can be used to recover the shard.
Yep that's fine, let's monitor the exception we catch here to be proactive.
Regarding the catching of exceptions, I am not sure that only ElasticsearchException are thrown by the call to actionGet, should we catch all Exception instead?
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 am not sure that only ElasticsearchException are thrown by the call to actionGet, should we catch all Exception instead?
That makes sense, done in b88fdc4
| POORLY_FORMATTED_BAD_REQUEST, | ||
| HUNSPELL_DICT_400 | ||
| HUNSPELL_DICT_400, | ||
| SYNONYMS_SET_LENIENT_ON_NON_EXISTING |
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.
That's just for tests no? Can we separate it and only add it when testing?
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.
Maybe create a test feature?
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.
Ah thanks, I'm too used to caps right now - changed on 636bea9
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.
Nice work Carlos!
| POORLY_FORMATTED_BAD_REQUEST, | ||
| HUNSPELL_DICT_400 | ||
| HUNSPELL_DICT_400, | ||
| SYNONYMS_SET_LENIENT_ON_NON_EXISTING |
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.
Maybe create a test feature?
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.
@carlosdelest Thanks for the quick work on this! Makes sense!
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.
LGTM
|
@elasticmachine run elasticsearch-ci/packaging-tests-windows-sample |
…existing-synonyms' into bugfix/synonyms-error-non-existing-synonyms
💔 Backport failed
You can use sqren/backport to manually backport by running |
(cherry picked from commit 968bddc) # Conflicts: # qa/mixed-cluster/build.gradle # rest-api-spec/build.gradle
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
(cherry picked from commit 968bddc) # Conflicts: # qa/mixed-cluster/build.gradle # rest-api-spec/build.gradle
(cherry picked from commit 968bddc)
(cherry picked from commit 968bddc) # Conflicts: # qa/mixed-cluster/build.gradle # rest-api-spec/build.gradle
Closes #125603
When a synonyms set does not exist, it doesn't fail shard recovery, but logs an INFO message and continues.
Using
lenient: falseon the synonym analyzer restores the previous behaviour, in which the shards cannot be allocated for the index.