-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Re-throw ResponseException as AssertionError in BasicLicenseUpgradeIT #67182
Conversation
It's possible that in a slow machine the cluster state updates take a while to be applied, the license information is published with priority NORMAL, meaning that it can take a while for the License information to become available. This can lead to race conditions. In order to wait until the license information is available, the tests use assertBusy, but assertBusy only retries if an AssertionException is raised, for that reason we rethrow http client exceptions as AssertionExceptions so the check can be retried. Closes elastic#64578
Pinging @elastic/es-distributed (Team:Distributed) |
Map<String, Object> licenseMap = (Map<String, Object>) licenseResponseMap.get("license"); | ||
assertEquals("basic", licenseMap.get("type")); | ||
assertEquals("active", licenseMap.get("status")); | ||
try { |
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.
Does this work as an alternative? This way it only retries on a 404:
final Request request = new Request("GET", "/_license");
request.addParameter("ignore", "404");
Response licenseResponse = client().performRequest(request);
assertOK(licenseResponse);
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 didn't know about the ignore
parameter, that looks much better 👍
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.
Full disclosure: nor did I until just now 😁
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
It's possible that in a slow machine the cluster state updates take a while to be applied, the license information is published with NORMAL priority, meaning that it can take a while for the License information to become available. This can lead to race conditions. In order to wait until the license information is available, the tests use assertBusy, but assertBusy only retries if an AssertionException is raised, for that reason we use the ignore parameter in the http client and later check that the response was correct, meaning that the check can be retried if the license information is not ready yet. Closes elastic#64578 Backport of elastic#67182
…#67212) It's possible that in a slow machine the cluster state updates take a while to be applied, the license information is published with NORMAL priority, meaning that it can take a while for the License information to become available. This can lead to race conditions. In order to wait until the license information is available, the tests use assertBusy, but assertBusy only retries if an AssertionException is raised, for that reason we use the ignore parameter in the http client and later check that the response was correct, meaning that the check can be retried if the license information is not ready yet. Closes #64578 Backport of #67182
It's possible that in a slow machine the cluster state updates take a while to be applied, the license information is published with NORMAL priority, meaning that it can take a while for the License information to become available. This can lead to race conditions. In order to wait until the license information is available, the tests use assertBusy, but assertBusy only retries if an AssertionException is raised, for that reason we use the ignore parameter in the http client and later check that the response was correct, meaning that the check can be retried if the license information is not ready yet. Closes elastic#64578 Backport of elastic#67182
…#68046) It's possible that in a slow machine the cluster state updates take a while to be applied, the license information is published with NORMAL priority, meaning that it can take a while for the License information to become available. This can lead to race conditions. In order to wait until the license information is available, the tests use assertBusy, but assertBusy only retries if an AssertionException is raised, for that reason we use the ignore parameter in the http client and later check that the response was correct, meaning that the check can be retried if the license information is not ready yet. Closes #64578 Backport of #67182
Relates: #110729 The `testQueryDLSFLSRolesShowAsDisabled` failed intermittently and my theory is that it's because applying the license of the cluster to cluster state has `NORMAL` priority and therefore sometimes (very rarely) takes more than 10 seconds. There are some related discussions to this, see: #67182, #64578 Since we're not testing the actual license lifecycle in this test, but instead how an applied license impacts the query roles API, I changed the approach to use the synchronous `/_license/start_trial` API in a `@before` so we can be sure the license was applied before we start testing. An alternative to this fix could be to increase the timeout.
Relates: elastic#110729 The `testQueryDLSFLSRolesShowAsDisabled` failed intermittently and my theory is that it's because applying the license of the cluster to cluster state has `NORMAL` priority and therefore sometimes (very rarely) takes more than 10 seconds. There are some related discussions to this, see: elastic#67182, elastic#64578 Since we're not testing the actual license lifecycle in this test, but instead how an applied license impacts the query roles API, I changed the approach to use the synchronous `/_license/start_trial` API in a `@before` so we can be sure the license was applied before we start testing. An alternative to this fix could be to increase the timeout.
Relates: elastic#110729 The `testQueryDLSFLSRolesShowAsDisabled` failed intermittently and my theory is that it's because applying the license of the cluster to cluster state has `NORMAL` priority and therefore sometimes (very rarely) takes more than 10 seconds. There are some related discussions to this, see: elastic#67182, elastic#64578 Since we're not testing the actual license lifecycle in this test, but instead how an applied license impacts the query roles API, I changed the approach to use the synchronous `/_license/start_trial` API in a `@before` so we can be sure the license was applied before we start testing. An alternative to this fix could be to increase the timeout.
Relates: elastic#110729 The `testQueryDLSFLSRolesShowAsDisabled` failed intermittently and my theory is that it's because applying the license of the cluster to cluster state has `NORMAL` priority and therefore sometimes (very rarely) takes more than 10 seconds. There are some related discussions to this, see: elastic#67182, elastic#64578 Since we're not testing the actual license lifecycle in this test, but instead how an applied license impacts the query roles API, I changed the approach to use the synchronous `/_license/start_trial` API in a `@before` so we can be sure the license was applied before we start testing. An alternative to this fix could be to increase the timeout.
It's possible that in a slow machine the cluster state updates
take a while to be applied, the license information is published
with NORMAL priority, meaning that it can take a while for the
License information to become available. This can lead to race
conditions. In order to wait until the license information is
available, the tests use assertBusy, but assertBusy only retries
if an AssertionException is raised, for that reason we use the
ignore
parameter in the http client and later check that theresponse was correct, meaning that the check can be retried
if the license information is not ready yet.
Closes #64578