-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Distinguish "missing repository" from "missing repository plugin" #82457
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
Distinguish "missing repository" from "missing repository plugin" #82457
Conversation
Currently it is possible to uninstall repository plugin before deleting repository that uses it. In such case the repository is still listed in the API however every interraction with it produces the "no such repository" exception. This is very confusing for the users. This change updates the error message to correctly point the root of the issue.
server/src/main/java/org/elasticsearch/repositories/MissingPluginRepository.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoriesService.java
Outdated
Show resolved
Hide resolved
DaveCTurner
left a comment
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.
Looks good @idegtiarenko, I left a few comments/suggestions.
server/src/main/java/org/elasticsearch/ElasticsearchException.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/MissingPluginRepository.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/MissingPluginRepository.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/MissingPluginRepository.java
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoriesService.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoriesService.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/repositories/RepositoriesService.java
Outdated
Show resolved
Hide resolved
server/src/test/java/org/elasticsearch/repositories/RepositoriesServiceTests.java
Outdated
Show resolved
Hide resolved
|
Pinging @elastic/es-distributed (Team:Distributed) |
| private static void assertThatThrows(ThrowingRunnable code, Class<? extends Exception> exceptionType, Matcher<String> messageMatcher) { | ||
| try { | ||
| code.run(); | ||
| } catch (Throwable e) { | ||
| assertThat(e, exceptionType, messageMatcher); | ||
| } | ||
| } | ||
|
|
||
| private static void assertThat(Throwable exception, Class<? extends Exception> exceptionType, Matcher<String> messageMatcher) { | ||
| assertThat(exception, isA(exceptionType)); | ||
| assertThat(exception.getMessage(), messageMatcher); | ||
| } |
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.
Is there a good common place to move this to? May be ESTestCase?
I am missing a simple way to assert exceptions in hamcrest similarly to what assertj offers: https://assertj.github.io/doc/#assertj-core-exception-assertions
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.
TBH we mostly don't care about the exception type, the message is the important bit. I think it'd fit somewhere in :test:framework:org.elasticsearch.test.hamcrest if you wanted to add a utility method for this tho.
|
@elasticmachine run elasticsearch-ci/rest-compatibility |
DaveCTurner
left a comment
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/part-2 |
The `RepositoryService` on each node maintains a repository instance for every repository defined in the cluster state. The master validates each repository definition before inserting it into the cluster state, but in some cases this validation is incomplete. For instance, there may be node-local configuration of which the master is unaware which prevents the repository from being instantiated on some other node in the cluster. Today if a repository cannot be instantiated then the node will log a warning and continue as if the repository doesn't exist. This results in a confusing `RepositoryMissingException` when trying to use the repository, and various other surprises (e.g. #85550). With this commit we create a placeholder `InvalidRepository` which reports a more accurate exception when it is used. Relates #82457 which did the same sort of thing for unknown plugins. Closes #85550 since the repository in question is no longer `null`.
Currently it is possible to uninstall repository plugin before
deleting repository that uses it. In such case the repository is still
listed in the API however every interraction with it produces the
"no such repository" exception. This is very confusing for the users.
This change updates the error message to correctly point the root of the
issue.
Closes: #81758