Fix failing applications navigation test #168302
Conversation
TinaHeiligers
added
Team:Core
|
verifying test stability: flaky test run build 3402 |
|
@elasticmachine merge upstream |
|
Pinging @elastic/kibana-core (Team:Core) |
| return await retry.waitForWithTimeout('navigates to app root', time ?? 3000, async () => { | ||
| return (await browser.getCurrentUrl()) === expectedUrl; | ||
| }); | ||
| }; | ||
| /** Use retry logic to make URL assertions less flaky */ | ||
| const waitForUrlToBe = (pathname?: string, search?: string) => { |
There was a problem hiding this comment.
The existing method relies on retry.waitFor.
I've been digging into the code, and found out that the waitFor implementation calls the waitForWithTimeout too.
It does so using timeouts.waitFor timeout config, which defaults to 20 seconds.
It's too bad that the CI artifacts collected upon failure can't show the browser URL bar, but I think that if this URL hasn't changed after 20 seconds, it likely won't change, so the problem must be somewhere else.
There was a problem hiding this comment.
Thanks for the tips, I'll look into it
There was a problem hiding this comment.
@gsoldevila it looks like most of the ftr tests not in x-pack that implement appsMenu.clickLink(title) directly are skipped, probably because they're failing.
The Dashboard tests aren't skipped though, so I implemented something similar.
Problem is, we still don't know what causes these failures and need to figure that out.
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
There was a problem hiding this comment.
I agree with @gsoldevila that I'm not sure this is going to solve anything given in the end, we're going the exact (just adding an additional wait gate via waitUntilLoadingIsDone)
However, we never know, and I don't see harm merging this to see if that solve the flakiness, so LGTM.
My 2 cps though:
The current error surfaced in #166677 is.
Error: timed out waiting for Url to be http://localhost:5620/app/foo/home
Can we at least modify this test's assertion so that when it fail, it displays the actual url so that we at least have the slightest idea of the problem the next time it fails? That's the only way I see to be able to really progress in this issue.
test/plugin_functional/test_suites/core_plugins/applications.ts
Outdated
Show resolved
Hide resolved
test/plugin_functional/test_suites/core_plugins/applications.ts
Outdated
Show resolved
Hide resolved
|
@elasticmachine merge upstream |
…rs/kibana into skipped-test-navigate-to-app
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
| @@ -80,8 +80,8 @@ export default function ({ | |||
| await testSubjects.missingOrFail('superDatePickerToggleQuickMenuButton'); | |||
| await testSubjects.existOrFail('globalQueryBar'); | |||
| }); | |||
|
|
|||
| it('renders as expected', async () => { | |||
| // failed test. See https://github.com/elastic/kibana/issues/163207 | |||
There was a problem hiding this comment.
This outer test suite (default URL params) was already skipped - is there a reason this inner test was also skipped? :)
|
@elasticmachine merge upstream |
TinaHeiligers
dismissed
gsoldevila’s stale review
We'll investigate deeper once we have the logs
|
@elasticmachine merge upstream |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
fix [elastic#166677 ](elastic#166677) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
FWIW we do have this information in the traces, that's how I found out that navigation was not taking place. |
fix #166677