Skip to content

Conversation

@carlosdelest
Copy link
Member

@carlosdelest carlosdelest commented Mar 26, 2025

Closes #125603

When a synonyms set does not exist, it doesn't fail shard recovery, but logs an INFO message and continues.

Using lenient: false on the synonym analyzer restores the previous behaviour, in which the shards cannot be allocated for the index.

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")
Copy link
Member Author

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

@carlosdelest carlosdelest added v8.18.1 v8.19.0 v9.0.1 :Search Relevance/Analysis How text is split into tokens auto-backport Automatically create backport pull requests when merged :SearchOrg/Relevance Label for the Search (solution/org) Relevance team Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch labels Mar 26, 2025
if (ignoreMissing == false) {
throw e;
}
logger.info(
Copy link
Contributor

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?

Copy link
Member Author

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?

- match: { hits.total.value: 1 }

---
"Fail loading synonyms from index if synonyms_set doesn't exist":
Copy link
Member Author

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

@carlosdelest carlosdelest marked this pull request as ready for review March 26, 2025 14:08
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search-relevance (Team:Search Relevance)

@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/search-eng (Team:SearchOrg)

@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/search-relevance (Team:Search - Relevance)

@carlosdelest carlosdelest requested review from a team and jimczi March 26, 2025 14:08
@carlosdelest carlosdelest changed the title Non existing synonyms sets does not fail shard recovery Non existing synonyms sets do not fail shard recovery Mar 26, 2025
Copy link
Contributor

@jimczi jimczi left a 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(
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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?

Copy link
Member Author

@carlosdelest carlosdelest Mar 27, 2025

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
Copy link
Contributor

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?

Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

@kderusso kderusso left a 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
Copy link
Member

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?

Copy link
Contributor

@mayya-sharipova mayya-sharipova left a 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!

@carlosdelest carlosdelest requested a review from jimczi March 27, 2025 06:53
Copy link
Contributor

@jimczi jimczi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@carlosdelest
Copy link
Member Author

@elasticmachine run elasticsearch-ci/packaging-tests-windows-sample

@carlosdelest carlosdelest enabled auto-merge (squash) March 27, 2025 12:05
@carlosdelest carlosdelest merged commit 968bddc into elastic:main Mar 27, 2025
16 of 17 checks passed
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
8.18 Commit could not be cherrypicked due to conflicts
8.x Commit could not be cherrypicked due to conflicts
9.0

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 125659

carlosdelest added a commit to carlosdelest/elasticsearch that referenced this pull request Mar 27, 2025
carlosdelest added a commit to carlosdelest/elasticsearch that referenced this pull request Mar 27, 2025
(cherry picked from commit 968bddc)

# Conflicts:
#	qa/mixed-cluster/build.gradle
#	rest-api-spec/build.gradle
@carlosdelest
Copy link
Member Author

💚 All backports created successfully

Status Branch Result
8.x
8.18

Questions ?

Please refer to the Backport tool documentation

carlosdelest added a commit to carlosdelest/elasticsearch that referenced this pull request Mar 27, 2025
(cherry picked from commit 968bddc)

# Conflicts:
#	qa/mixed-cluster/build.gradle
#	rest-api-spec/build.gradle
carlosdelest added a commit to carlosdelest/elasticsearch that referenced this pull request Mar 28, 2025
breskeby pushed a commit that referenced this pull request Mar 28, 2025
omricohenn pushed a commit to omricohenn/elasticsearch that referenced this pull request Mar 28, 2025
carlosdelest added a commit to carlosdelest/elasticsearch that referenced this pull request May 9, 2025
(cherry picked from commit 968bddc)

# Conflicts:
#	qa/mixed-cluster/build.gradle
#	rest-api-spec/build.gradle
elasticsearchmachine pushed a commit that referenced this pull request May 23, 2025
#125479) (#127981)

* Non existing synonyms sets do not fail shard recovery (#125659)

(cherry picked from commit 968bddc)

# Conflicts:
#	qa/mixed-cluster/build.gradle
#	rest-api-spec/build.gradle

* Fix backport merge
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

auto-backport Automatically create backport pull requests when merged backport pending >bug :Search Relevance/Analysis How text is split into tokens :SearchOrg/Relevance Label for the Search (solution/org) Relevance team Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch v8.18.1 v8.19.0 v9.0.1 v9.1.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Synonyms API: Index gets red status when synonyms set does not exist

5 participants