-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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 a few dashboard flaky tests #22901
Fix a few dashboard flaky tests #22901
Conversation
b3465cc
to
3c8623c
Compare
@@ -24,79 +24,76 @@ export default function ({ getService, getPageObjects }) { | |||
const retry = getService('retry'); | |||
const PageObjects = getPageObjects(['common', 'discover', 'visualize', 'header']); | |||
|
|||
describe('visualize app', function describeIndexTests() { |
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.
just removed the unnecessary wrapper
💔 Build Failed |
5776953
to
28a2a5e
Compare
💚 Build Succeeded |
retest |
💚 Build Succeeded |
retest |
💔 Build Failed |
Failed on a flaky test
jenkins, test this |
💔 Build Failed |
|
Generalize the fix and include some other flakiness encountered with slow network connection dont wrap in a retry or stale element checks will get caught dont click disabled go button Skip test hitting legit input control bug
28a2a5e
to
d07b314
Compare
💔 Build Failed |
Failed on jenkins, test this |
This last failure was; That test has only failed 2 other times in the last 30 days. Both of those were on Sept 11th on @ppisljar's PR #22756 (which is now merged) but I don't know if his PR had anything to do with that test. I don't see any changes to tests in that PR. If this PR is adding the check to see if something is disabled then this failure might be related (this is from this PR's last failing build);
It doesn't look like we captured a screenshot or page source for some reason on this failure so it's hard to know why the visualizeEditorRenderButton was not enabled. |
it might be a legit bug. I ran into a situation last week where the play button became disabled and it wasn't becoming enabled. I couldn't repro through, once I refreshed the page. I won't submit until these issues are worked out, but this is partly why I'm concerned that swapping out an entire test backend for all tests is going to be a huge issue. Slight timing changes can expose legit bugs and more flakiness. Look at this PR: #22787 When I ran the
|
💔 Build Failed |
After discover the "slow 3g" option in Chrome, I was able to reproduce many flaky dashboard issues.
clickNewDashboard
checked for anadd dashboard
button, if it didn't exist, it tried until failure to find the button on the prompt. Problem is sometimes it was slow to render the page, so dashboards existed, and theadd dashboard
button just didn't render yet. But once it failed to find it, it assumed there were no dashboards and only waited to find the "add your first dashboard" prompt button.similarly,
gotoDashboardLandingPage
first checked for the existence of an item to determine where it was, but if that came back incorrectly (because the page was slow to load), it would fail. Wrapping both checks in a retry should fix this.The second
click save
button happened too quickly, this waits for the button to be enabled before clicking. Clicking the button when disabled doesn't throw an error. Rather than fix for this specific test, I pushed the check for a disabled button into the find service so any other clicks on an element will wait for the button to be enabled, or will throw an error as unsuccessful.Added in a check to wait for the EuiTableLoading indicator to be removed after searching for a dashboard on the listing page. If it's in the process of loading, some clicks can miss their elements.
Fixes #22409 ... probably many more! 🎉