-
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
Fix flaky test addSnapshotLifecyclePolicy #46881
Fix flaky test addSnapshotLifecyclePolicy #46881
Conversation
Drop async call to put the policy as we are not waiting for the result as we are synchronously creating it already (the async nature of the second create request made this test flaky as we're asserting the version of the policy to be 1)
Pinging @elastic/es-core-features |
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 for taking a look at this Andrei, I left comments about what these unused blocks of code are for and why we shouldn't remove them.
@@ -797,32 +797,11 @@ public void testAddSnapshotLifecyclePolicy() throws Exception { | |||
// end::slm-put-snapshot-lifecycle-policy-response | |||
assertTrue(putAcknowledged); | |||
|
|||
// tag::slm-put-snapshot-lifecycle-policy-execute-listener | |||
ActionListener<AcknowledgedResponse> putListener = |
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.
These are here because they are used as snippets to generate the high level rest client documentation (that's what the surrounding // tag::etcetc
and // end::etcetc
are for, so I don't think we should remove these
@@ -858,18 +838,7 @@ public void onFailure(Exception e) { | |||
SnapshotLifecyclePolicyMetadata policyMeta = | |||
getResponse.getPolicies().get("policy_id"); // <1> | |||
long policyVersion = policyMeta.getVersion(); | |||
long policyModificationDate = policyMeta.getModifiedDate(); |
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.
Even though these appear unused, they are documenting how to retrieve things from the policy metadata, so we should leave them. See get_snapshot_lifecycle_policy.asciidoc
for the callout usages
// end::slm-put-snapshot-lifecycle-policy-execute-listener | ||
|
||
// tag::slm-put-snapshot-lifecycle-policy-execute-async | ||
client.indexLifecycle().putSnapshotLifecyclePolicyAsync(request, |
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 think rather than remove this (which we need for documentation), we should relax or remove the assertion to not trip on the policy version.
This reverts commit af42449.
This reverts commit 32fa9d7.
This drops the assertion on the policy version (which was pinned to 1L) as we want to execute both put policy apis (sync and async) for documentation purposes. This will sometime (depending on the async call) yield a version of 2L. Waiting for the async call to always complete could be an option but the test is already rather slow and it's a bit of an overkill as we're already verifyin the policy was created.
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
retest this please |
* addSnapshotLifecyclePolicy drop version assertion This drops the assertion on the policy version (which was pinned to 1L) as we want to execute both put policy apis (sync and async) for documentation purposes. This will sometimes (depending on the async call) yield a version of 2L. Waiting for the async call to always complete could be an option but the test is already rather slow and it's a bit of an overkill as we're already verifying the policy was created. (cherry picked from commit af4864c) Signed-off-by: Andrei Dan <[email protected]>
* addSnapshotLifecyclePolicy drop version assertion This drops the assertion on the policy version (which was pinned to 1L) as we want to execute both put policy apis (sync and async) for documentation purposes. This will sometimes (depending on the async call) yield a version of 2L. Waiting for the async call to always complete could be an option but the test is already rather slow and it's a bit of an overkill as we're already verifying the policy was created. (cherry picked from commit af4864c) Signed-off-by: Andrei Dan <[email protected]>
* addSnapshotLifecyclePolicy drop version assertion This drops the assertion on the policy version (which was pinned to 1L) as we want to execute both put policy apis (sync and async) for documentation purposes. This will sometimes (depending on the async call) yield a version of 2L. Waiting for the async call to always complete could be an option but the test is already rather slow and it's a bit of an overkill as we're already verifying the policy was created. (cherry picked from commit af4864c) Signed-off-by: Andrei Dan <[email protected]>
* addSnapshotLifecyclePolicy drop version assertion This drops the assertion on the policy version (which was pinned to 1L) as we want to execute both put policy apis (sync and async) for documentation purposes. This will sometimes (depending on the async call) yield a version of 2L. Waiting for the async call to always complete could be an option but the test is already rather slow and it's a bit of an overkill as we're already verifying the policy was created. (cherry picked from commit af4864c) Signed-off-by: Andrei Dan <[email protected]>
Fixes #46021
gradle check
?