-
Notifications
You must be signed in to change notification settings - Fork 115
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
AD test failure fix #227
Merged
amitgalitz
merged 4 commits into
opensearch-project:main
from
amitgalitz:fix-ad-test-wait
May 17, 2022
Merged
AD test failure fix #227
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
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
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.
😭
Is there an API call that you can intercept and wait until that finishes to continue?
If not, we can also extend the functionality of
opensearch-dashboards-functional-test/cypress/utils/commands.js
Line 70 in 25afb70
{ timeout: xxxx }
for cy.get [doc]. That way it will navigate to the page and check for longer that the default amount. But if it finds it earlier then it will continue.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 second option makes sense to me, I don't think there is an API call that we can intercept easily. However I am still trying to figure out why this really sometimes helps but its pretty hard to replicate locally.
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.
With the second option? Or just adding a timeout in general?
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 adding the timeout itself in this case on the AD test even. For adding the timeout on the get command for all tests, I can easily do that, just seems like it could add a lot of unnecessary time to all tests.
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, just to clarify I mean extending it in the way that makes the timeout configurable. RIght now it has the default timeout and when you pass that command if you increase for example to 1 minute (
{ timeout: 60000}
). It will tell cypress to keep retrying for 1 minute to find the element. But if it finds it in 3 seconds it will continue the test path and not wait for the whole minute. The point where it will increase the time for all tests if all tests actually end up failing to find the element but generally all tests shouldn't experience an increase wait time. This is compared to the arbitrary wait for 3 seconds where it will wait for 3 seconds then move to the next line. But if it actually required 4 seconds then the test will still fail.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 moved the wait time inside this function as it seemed to help with the issue the most, since it isn't part of
getElementByTestId
do you recommend moving the wait to the next line of: https://github.com/opensearch-project/opensearch-dashboards-functional-test/pull/227/files#diff-1544ad6eba828cbcff2b11e02c24a29dfa194e5da1cc11de42463f46c3511073R53. For adding the functionality since default is 60s, it would have to be passed with 61000? It doesn't seem to be dependent on the 60 second wait time itself since just 1 second more or even .5 seconds solves the issue which makes me wary of just increasing that wait time. It more seems to be the transition between this line (cy.get('.euiFilterSelectItem').first().click();
) and then clicking the next.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.
Agree with @amitgalitz here, the issue is related to not enough time within
selectTopItemFromFilter
to load the data and perform the action, such that it gets hung and the runner is not able to click to the next page regardless of the 60s timeout, because the page gets stuck in a weird state. I think the fix makes sense hereThere 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.
Per Cypress guidance, it is anti-pattern to have an explicit wait. Totally understand that this has already been used in other test cases. Just try to see if this is a low hanging fruit to fix. By checking more into the Cypress best practice, I think we can add an assertion for the
get
which can function as waiting and then try to chain into it.@amitgalitz @ohltyler
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.
Thats a fair point, I'll send an additional PR this week removing the explicit wait and hopefully other uses of it in AD tests