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 |
dakrone
left a comment
There was a problem hiding this comment.
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.
| assertTrue(putAcknowledged); | ||
|
|
||
| // tag::slm-put-snapshot-lifecycle-policy-execute-listener | ||
| ActionListener<AcknowledgedResponse> putListener = |
There was a problem hiding this comment.
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
| SnapshotLifecyclePolicyMetadata policyMeta = | ||
| getResponse.getPolicies().get("policy_id"); // <1> | ||
| long policyVersion = policyMeta.getVersion(); | ||
| long policyModificationDate = policyMeta.getModifiedDate(); |
There was a problem hiding this comment.
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.
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.
|
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 <andrei.dan@elastic.co>
* 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 <andrei.dan@elastic.co>
* 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 <andrei.dan@elastic.co>
* 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 <andrei.dan@elastic.co>
Fixes #46021
gradle check?