-
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
Search Sessions: Improve Flaky Functional Test #89370
Conversation
Pinging @elastic/kibana-app-services (Team:AppServices) |
describe('New search sessions', () => { | ||
before(async () => { | ||
await PageObjects.common.navigateToApp('dashboard'); | ||
log.debug('wait for dashboard landing page'); | ||
retry.tryForTime(10000, async () => { |
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.
If we are on a loading screen, dashboard.loadSavedDashboard
has flaky behavior: it wants to take us to the landing page, so tries to click a breadcrumb. But then the loading screen goes away and we are on the landing page. The landing page doesn't have a breadcrumb to itself, so dashboard.loadSavedDashboard
breaks.
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.
doesn't navigateToApp('dashboard');
always take us to the landing page? I would think if that navigate method always sets the URL and uses the timestamp hash that it would reliably be on the landing page? I think some dashboard tests did something to avoid the timestamp hash in the URL to preserve state. Maybe that's related.
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.
It takes us to the landing page, which could actually be displaying a loading screen. This retry waits until any loading screen is cleared.
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.
Thanks for the slow proxy tip!
It is also worth running through flaky test runner for the piece of mind
@elasticmachine merge upstream |
merge conflict between base and head |
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
The test may still be flaky |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
I started a flaky test runner job on this PR https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/1203 |
* Search Sessions: Unskip Flaky Functional Test * typo * keep skip for now Co-authored-by: Kibana Machine <[email protected]>
* Search Sessions: Unskip Flaky Functional Test * typo * keep skip for now Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Kibana Machine <[email protected]>
Summary
Part of #89069
I ran the functional test runner against a dev proxy to the test server to emulate a slow connection between the browser and Kibana server:
When the browser was slowed down, I could reproduce some forms of test failures. This PR addresses the flakiness, so that tests pass when the browser connections are slow.