[Flaky Test] Fixes Space Navigation Race Condition#147193
[Flaky Test] Fixes Space Navigation Race Condition#147193jeramysoucy merged 3 commits intoelastic:mainfrom
Conversation
jeramysoucy
added
Team:Security
|
Pinging @elastic/kibana-security (Team:Security) |
jeramysoucy
added
the
release_note:skip
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Unknown metric groupsESLint disabled in files
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
thomheymann
left a comment
thomheymann
left a comment
There was a problem hiding this comment.
LGTM, one question below
| @@ -205,6 +205,7 @@ export class SpaceSelectorPageObject extends FtrService { | |||
| this.log.info(`SpaceSelectorPage:goToSpecificSpace(${spaceId})`); | |||
| await this.testSubjects.click(`${spaceId}-selectableSpaceItem`); | |||
| await this.common.sleep(1000); | |||
There was a problem hiding this comment.
Do we still need this artificial timeout now that we're checking for the menu to be closed?
There was a problem hiding this comment.
I was inclined to leave it in because there seems to sometimes be a delay between the click and the closing of the menu/redirect. Without it, it may be possible for another race condition resulting in the space item not even being there on the next retry.
If this doesn't solve the problem we were seeing, I think I will refactor the test to be as deterministic as possible, in which case we can take out the delay.
|
Ran the Flaky TR on test/server_integration/http/platform/config.status.ts as well, due to CI result. |
5 participants
Resolves #142155
Flakiness appears to be due to a race condition of clicking on a space item in the menu before the item is responsive to interaction. This PR attempts to confirm the space item click by checking the menu is no longer present, before moving on the verify the new space in the URL.
Flaky Test Runner Results