-
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
SO Tagging: fix flaky test and re-enable it #82930
SO Tagging: fix flaky test and re-enable it #82930
Conversation
await PageObjects.visualize.gotoVisualizationLandingPage(); | ||
await PageObjects.header.waitUntilLoadingHasFinished(); |
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.
Suggestion: There could be a lot of reasons for waiting for a DOM element to be rendered. What if we increase timeout
in selectFilterTags
method instead?
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.
TBH after 100 runs against my local I couldn't reproduce the flaky failure even once. The failure message indicates that for some reason, 1. the tag filter was not applied (Visualization 2 (tag-2)
is present in the table) and 2. the new vis was not created (My new markdown viz
is not), and I don't really how we could come as far as the last assertion in that state without failing before in the test. So I kinda did the best I could with additional synchronizations / waiting steps to see if that would resolves it on CI (renamed the PR accordingly).
I can do what you suggest though
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.
@pgayvallet Have you tried to leverage https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/build
to run a flaky test on CI?
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 did not. Can this be ran against a PR branch?
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.
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.
First run had a failure on another test - https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/978/testReport/junit/X-Pack%20Saved%20Object%20Tagging%20Functional%20Tests/x-pack_test_saved_object_tagging_functional_tests_dashboard_integration%C2%B7ts/Kibana_Pipeline___agent_2___saved_objects_tagging___functional_tests_dashboard_integration_creating_allows_to_create_a_tag_from_the_tag_selector/
but the error message was a little more explicit on that one. trying something else by waiting for the table to load
- https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/986/
- https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/989/
- https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/996/
- https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/997/
- https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/1002/
To reviewers: sorry, please don't mind this PR. Had to edit the test file ci groups to avoid the flaky test runner to run all the group. You can safely unsubscribe. |
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.
ML changes LGTM
Edit:
To reviewers: sorry, please don't mind this PR. Had to edit the test file ci groups to avoid the flaky test runner to run all the group. You can safely unsubscribe.
Noticed this one too late 😅
Ran 3*200 using the flaky test runner, without failure. Seems that the additional table await is a correct fix. https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/996/ |
@@ -133,7 +139,10 @@ export default function ({ getPageObjects, getService }: FtrProviderContext) { | |||
expect(await tagModal.isOpened()).to.be(false); | |||
|
|||
await testSubjects.click('confirmSaveSavedObjectButton'); | |||
await PageObjects.common.waitForSaveModalToClose(); |
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.
do we still need it?
await PageObjects.visualize.gotoVisualizationLandingPage(); | ||
await listingTable.waitUntilTableIsLoaded(); |
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 still don't understand whether we can get rid of this instruction in the test suit. As suggested in #82930 (comment)
IMO, It's okay in the preparatory phase but hard to debug in the test suite, so people start adding them all over the places.
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.
There were some rare race conditions where the elements we are manipulating in the next instructions of the test were already removed from the DOM, because we retrieved them before the table was loaded (which cause a rerender, causing some existing dom elements to be removed from the document). This additional check is meant to fix the race by waiting for the next refresh
…-vis-flacky-ftr-1
…-vis-flacky-ftr-1
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
* fix flaky test and re-enable it * wait for table to load before to perform operations * move everything out of ciGroup2 for flaky test runner * add debug block for flaky runner * use correct vis name * remove test sync * Revert "move everything out of ciGroup2 for flaky test runner" This reverts commit db86c3b
* fix flaky test and re-enable it * wait for table to load before to perform operations * move everything out of ciGroup2 for flaky test runner * add debug block for flaky runner * use correct vis name * remove test sync * Revert "move everything out of ciGroup2 for flaky test runner" This reverts commit db86c3b
…o-node-details * 'master' of github.com:elastic/kibana: SO Tagging: fix flaky test and re-enable it (elastic#82930) [Metrics UI] Converting legend key to optional (elastic#83495)
…t/saved_object_tagging/functional/tests/maps_integration·ts - saved objects tagging (#149356) Fixes #89073 and #106547 Flaky test runner https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/1785 Issue with flaky maps_integration.ts is that there was not await when filtering maps list by tags. This resulted in list page refreshing after `const links = await this.find.allByCssSelector('.euiTableRow-isSelectable .euiLink');` and then getting an elemented unmounted on future `await links[i].getVisibleText()` calls. A [similar fix](#82930) was implemented for visualize and dashboard listing pages. #82930 introduced `listingTable.waitUntilTableIsLoaded` but did not introduce the method in a consistent way. Other methods that search table were not updated to use `listingTable.waitUntilTableIsLoaded`, but instead used `this.header.waitUntilLoadingHasFinished()`. This PR resolved this issue by updating all listingTable methods that search to use `listingTable.waitUntilTableIsLoaded` and then updated `listingTable.waitUntilTableIsLoaded` with a call to `this.header.waitUntilLoadingHasFinished()` #82930 did not update maps_integration tests, only resolving the issue for visualize and dashboard. To avoid future situations where fixes only resolve a few usages, this PR moves selectFilterTags into listing_table and replaces all implementations of selectFilterTags with listingTable.selectFilterTags. While investigating dashboard_integrations test, I found `x-pack/test/functional/apps/dashboard/group2/dashboard_tagging.ts`, which duplicated most of dashboard_integrations test. This PR removes x-pack/test/functional/apps/dashboard/group2/dashboard_tagging.ts adds the unique test case to dashboard_integrations Co-authored-by: kibanamachine <[email protected]>
…t/saved_object_tagging/functional/tests/maps_integration·ts - saved objects tagging (elastic#149356) Fixes elastic#89073 and elastic#106547 Flaky test runner https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/1785 Issue with flaky maps_integration.ts is that there was not await when filtering maps list by tags. This resulted in list page refreshing after `const links = await this.find.allByCssSelector('.euiTableRow-isSelectable .euiLink');` and then getting an elemented unmounted on future `await links[i].getVisibleText()` calls. A [similar fix](elastic#82930) was implemented for visualize and dashboard listing pages. elastic#82930 introduced `listingTable.waitUntilTableIsLoaded` but did not introduce the method in a consistent way. Other methods that search table were not updated to use `listingTable.waitUntilTableIsLoaded`, but instead used `this.header.waitUntilLoadingHasFinished()`. This PR resolved this issue by updating all listingTable methods that search to use `listingTable.waitUntilTableIsLoaded` and then updated `listingTable.waitUntilTableIsLoaded` with a call to `this.header.waitUntilLoadingHasFinished()` elastic#82930 did not update maps_integration tests, only resolving the issue for visualize and dashboard. To avoid future situations where fixes only resolve a few usages, this PR moves selectFilterTags into listing_table and replaces all implementations of selectFilterTags with listingTable.selectFilterTags. While investigating dashboard_integrations test, I found `x-pack/test/functional/apps/dashboard/group2/dashboard_tagging.ts`, which duplicated most of dashboard_integrations test. This PR removes x-pack/test/functional/apps/dashboard/group2/dashboard_tagging.ts adds the unique test case to dashboard_integrations Co-authored-by: kibanamachine <[email protected]>
Summary
Fix #82556