-
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
[Discover] Unskip functional tests for field visualize buttons #62614
Merged
kertal
merged 27 commits into
elastic:master
from
kertal:kertal-pr-2020-04-02-discover-unskip-field-visualize-functional
Apr 22, 2020
Merged
Changes from 12 commits
Commits
Show all changes
27 commits
Select commit
Hold shift + click to select a range
ca8965b
Unskip test
kertal 12fdaba
Add visualize button test in OSS
kertal 3e9b076
Remove other discover tests
kertal e55fdde
Implement retry for flaky tests
kertal 9e3e00a
Remove before code that failed
kertal afc9ff3
Improve retry code
kertal f1ee00f
Apply fix to discover security and spaces
kertal 021c32d
Merge upstream/master, fix conflicts
kertal ff5895e
Undo _discover.js changes
kertal 0088147
Add missing retry service to discover_security.ts
kertal d318d32
Fix security bugs
kertal f95faa7
Merge branch 'master' into kertal-pr-2020-04-02-discover-unskip-field…
elasticmachine e73cd0b
Adapt tests to use PageObjects.discover.getHitCount()
kertal d9737d3
Merge remote-tracking branch 'upstream/master' into kertal-pr-2020-04…
kertal d11190d
Merge branch 'kertal-pr-2020-04-02-discover-unskip-field-visualize-fu…
kertal 8cff5ef
fix tests that expect the visualize button not to exist
kertal 1a368b3
Add debugging
kertal 49974e4
Increase waitForCompletionTimeout to 5s
kertal a50a210
Merge remote-tracking branch 'upstream/master' into kertal-pr-2020-04…
kertal cc76e78
Undo test adaptions
kertal 1986411
Modify async search code
kertal 6688d68
Merge remote-tracking branch 'upstream/master' into kertal-pr-2020-04…
kertal 51f52bc
undo wait for completion timeout setting too 5s
kertal ba1dbbf
resolves #64132
c6688fb
simplify condition
934db8e
Merge async fix
kertal 63aa5df
Merge upstream/master, fix conflicts
kertal File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 would generally try to avoid checking for something to not exist since it takes a timeout of 10 seconds or so. Compared to checking for something that should exist like the hit count. Don't change anything yet. I'm going to run these tests locally and see if I have a suggestion for a change.
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.
The current code as it retries a couple of times to make sure it's not on the "no results" page (it's not the default timeout, but a 2500ms timeout) takes about 3 seconds;
vs getting the hitCount and verifying it's > 0 takes about .2 seconds
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.
Sorry but I just realized another potential issue with this change.
In other Discover tests we've used a retry only around getting the hit count and comparing it to the expected value. We didn't include setting the time range in the retry because each time you set the timepicker it's going to reload the page, and it's the page loading we're waiting for with the retry.
From the failing test issue you said
"the screenshot of the failed test is telling me, no data available, expand your time range. that's odd"
Did the screenshot show the expected start and end dates?
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.
thx @LeeDr , back today, I'll soon provide feeback
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.
About the screenshot, yes it's showing the defined time range, but no data:

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've run a similar test suite in OSS for debugging the issue, it's wasn't flaky there:
https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/339/
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.
dear @LeeDr, wonder how to proceed here?
Maybe switch to
const hitCount = await PageObjects.discover.getHitCount();
, since this fixes the test, and open another issue because of the flaky data fetching to investigate?Thx!
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 find it pretty concerning that the screenshot shows the correct dates in the timepicker and no results?!?! It could still just be a timing issue that the results just haven't come back in the response yet, but the pink loading bar isn't there either so that doesn't feel right.
I'm looking at the flaky-test-suite-runner output now....
FYI, here's an example of a test where we only put the getHitCount() in the retry because it's waiting for the response from Elasticsearch and for the page to load that data; https://github.com/elastic/kibana/blob/master/test/functional/apps/discover/_discover.js#L74
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.
@LeeDr I've adapted the code, removing setDiscoverTimerRange() of
try.retry
, now the flaky suite is flaky (1 of 44)https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/367/
can I search the logs on server? because in Jenkins it's hard to search the logs, it says, no test failed
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.
/cc @lukasolson (any other thoughts on this?)
I had a couple of thoughts on debugging this while running the test locally.
We could turn on Elasticsearch slowlogs on both the
logstash-*
and.async-search
indices. I don't see that we've done that in any existing tests yet. It's a per-index setting. Seems like it would have to be done afteresArchiver.loadIfNeeded('logstash_functional');
. But the slowlog only shows the query, not the response. So this might not help in debugging the issue.Another thing you could try, is if we fail to find hit count, or if we do find the "no results" page, is to try to open the inspector and capture the request and response. It could show that either the query sent was wrong, or the query was right and Elasticsearch didn't return the correct response, or the correct response was returned and Discover didn't display it.
Or temporarily add debug logging to output the query and response to the Kibana log.