-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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 for legacy authorization #87642
Conversation
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
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
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, does seem like we had some unnecessary leftover there.
Thanks for cleaning that up.
* Unskip test * Increase attempts to 2 for retryIfConflicts * Cleanup authorization for updateApiKey
* Unskip test * Increase attempts to 2 for retryIfConflicts * Cleanup authorization for updateApiKey
Resolves #87010.
Resolves #87098.
Resolves #86952.
The flaky test #87010 uncovered a single occurrence of two things:
retryIfConflicts
attemptsupdateApiKey
when it should have been unauthorizedIn this PR, I've increased the
retryIfConflicts
attempts from1
to2
for the special case that does happen. For the authorization allowing theupdateApiKey
call, I couldn't reproduce this, and it could have been fixed already with a PR between then and now. Due to not being able to reproduce and discover the underlying cause, I cleaned up some code that no longer seemed necessary in theupdateApiKey
function. I hope this may help or resolve the flaky scenario.Flaky test runs: