Skip to content
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

Merged

Conversation

pgayvallet
Copy link
Contributor

Summary

Fix #82556

@pgayvallet pgayvallet marked this pull request as ready for review November 9, 2020 11:40
@pgayvallet pgayvallet requested a review from a team as a code owner November 9, 2020 11:40
@pgayvallet pgayvallet added release_note:skip Skip the PR/issue when compiling release notes v7.11.0 v8.0.0 labels Nov 9, 2020
await PageObjects.visualize.gotoVisualizationLandingPage();
await PageObjects.header.waitUntilLoadingHasFinished();
Copy link
Contributor

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?

Copy link
Contributor Author

@pgayvallet pgayvallet Nov 9, 2020

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

Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can configure it
2020-11-10_12-30-14

@pgayvallet pgayvallet changed the title SO Tagging: fix flaky test and re-enable it SO Tagging: attempt to fix flaky test and re-enable it Nov 9, 2020
@pgayvallet pgayvallet requested review from a team as code owners November 12, 2020 12:33
@pgayvallet
Copy link
Contributor Author

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.

Copy link
Member

@pheyos pheyos left a 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 😅

@pgayvallet pgayvallet removed request for a team November 16, 2020 13:41
@pgayvallet
Copy link
Contributor Author

@pgayvallet pgayvallet requested a review from mshustov November 16, 2020 13:43
@pgayvallet pgayvallet changed the title SO Tagging: attempt to fix flaky test and re-enable it SO Tagging: fix flaky test and re-enable it Nov 16, 2020
@@ -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();
Copy link
Contributor

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();
Copy link
Contributor

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.

Copy link
Contributor Author

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

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

✅ unchanged

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@pgayvallet pgayvallet merged commit b3eefb9 into elastic:master Nov 18, 2020
pgayvallet added a commit to pgayvallet/kibana that referenced this pull request Nov 18, 2020
* 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
pgayvallet added a commit that referenced this pull request Nov 18, 2020
* 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
phillipb added a commit to phillipb/kibana that referenced this pull request Nov 18, 2020
…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)
nreese added a commit that referenced this pull request Jan 26, 2023
…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]>
kqualters-elastic pushed a commit to kqualters-elastic/kibana that referenced this pull request Feb 6, 2023
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore release_note:skip Skip the PR/issue when compiling release notes v7.11.0 v8.0.0
Projects
None yet
4 participants