-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Page occasionally does not load from cy.visit() #2938
Comments
Does this happen during |
We also have the same problem - I've been spending alot of time investigating this - I wrote up my findings so far on this issue: but I've definitely ruled out visiting the same url as the cause of the problem - I was about to raise a new issue when I saw this. I've only ever seen the problem on As I say in the link - our server definitely responds with the correct and identical html, but its stalled. It looks like it is something to do with the way in which the initial result is redirected to the proxy - but my knowledge of the inner workings of cypress are preventing me getting further. I'm happy to add any logging or run a special debug version. |
I've tried:
Is there some way to catch the visit failure and try visiting again? |
Thanks for the additional info @lukeapage! @jennifer-shehane I believe I have seen it with |
I’ve ended up solving our problems by retrying : |
That is a decent workaround. I'm hesitant to implement auto retries because it will allow for sloppier test writing. If there was a way to implement it for just this issue I'd be all over it. |
You may be able to - if the cli returns the reason for the failures, you can alter that script to only retry tests where this is the problem. My plan is that for CI and getting PR approval, I will allow retry. But I also have a scheduled run of 20x on master where I will disable retry. Any intermittant failures coming up from that can then be investigated. However I am wondering how even that will work out - I've spent alot of time fixing intermittant failures the last 5 days and #695 is a big source of problems (click does not retry the get if the element is not visible) and quite often there are situations where it is very difficult to assert with a should in order to make sure the click definitely won't fail.. thats alot of effort that I am not sure if it is worth it, espescially if the cypress team fix #695 . So far it looks like this issue and that issue are the main causes and everything else is a real app problem that should be fixed. |
We're in the same situation, one of the commenters on #695 is my teammate. Besides that issue we've been able to fix all intermittent failures with either a Thanks, I may look into modifying the retry script in January - higher priority things right now, then we're shut down for the holidays. |
I get the same error running on my development computer using MAMP. The error arises in different specs but only when I choose to "Run all specs". The error is somewhat random as different specs fail in different places, though some seem to fail more than others. This is happening where there is a valid target to click() using cy.get() (rather than using cy.visit() to a specific url). I find that the url is always opened correctly when I run each spec individually. I'll take a look at the work around, but it doesn't appear to be ideal. |
@Wolsten that sounds like a different issue. This issue is about a page not loading from |
@drewbrend, thanks for the feedback. I tried replacing the get click with visit(url) and I see the same error, it doesn't appear to matter how the url is determined. The test in question runs fine every time I run in isolation but always times out when run in a sequence of tests. The strange thing is going back through the snapshots, the one for the page I requested through visit(url) is correctly displayed and the following get([name=title] succeeds as shown in the attached screenshot. |
A question about a possible work around. As the specs run without problem individually, is there a "before" command I could use to reinitialise the state of Cypress? I tried putting in a cy.wait(10000) in the "before" block but this didn't help. |
There may be an intermittent issue involving the page load event, as I myself have this issue with one of our Cypress projects - this is the isolating factor though. I only have it on our Dashboard project, no other project. I've isolated a few instances in the past 6 months from our develop branch: CircleCI IDs: Video of failure - looks like the url may have gotten in a weird state before beginning test? |
@jennifer-shehane you have marked it "needs information" - is there anything we can add? If I were you I would enhance logging, release a new version and then ask for logs of when it occurs again. |
@jennifer-shehane I suspect that my issue is due to Ajax calls not being fully completed. For example, I update a page via an Ajax call and then click a pre-existing navigation element on the page - but not all new data has been loaded from the Ajax call. This is shown, for example, by tables with only partially drawn new rows in the captured screenshot. I have managed to get a much more stable environment by testing for page elements that should be generated by Ajax commands (I guess this is the right thing to do anyway) and also by extending the "pageLoadTimeout" to 600,000 (this appears to be critical). What would be helpful would be a mechanism to identify exactly which page load url (ajax call) is causing the problem as the error message is often unrelated to the preceding step. If as @drewbrend suspects this is a separate issue would you like me to open a new one to this effect? |
I also want to make sure everyone visiting this issue is aware of a known issue when calling cy.visit() to a url that you are currently navigated to - #1311 It exhibits the exact same error of timing out waiting for the 'load' event - so ensure this is not the case for you - you likely would not be intentionally visiting the same url twice, but your application may be rerouting and end up visiting the exact url you are already on. |
@jennifer-shehane I'm not sure if that is the same issue. We are calling
|
Unfortunately I cannot offer much more detail, but we are experiencing this on a Mac - Linux machines run the spec fine every time, but the Mac will always fail at the exact same point. Essentially the test looks like this: export const goToLoginPage = () => {
cy.visit('/', {
onBeforeLoad: win => {
win.sessionStorage.clear();
}
});
};
describe('Account scenarios', () => {
it('Users can view their account details', () => {
// All three run without issues
[kim, david, keith].map(user => {
goToLoginPage();
logInAsUser(user);
clickAccount();
verifyAccountDetails(user);
});
});
it('Kim can change her default location', () => {
// Mac always fails with a timeout here, URL '/' never loads and the browser still shows the previous '/account' path after calling goToLoginPage. Linux works every time so far.
goToLoginPage();
logInAsUser(kim);
clickAccount();
verifyDefaultLocationDropDown();
});
}); So essentially we are logging in 4 times and on the Mac the 4th time it will consistently fail to navigate to |
@jennifer-shehane I have to run regression , but once in a while the Now I am not able to run regression due to this issue. Can you please check its blocking whole regression. given('recruiter is logged in', () => {
cy.clearCookies();
cy.visit('/' + '?policy=accepted');
cy.visit('/werkgever/inloggen');
Login.typeRecruiterCredentials('');
cy.submit();
cy.url().should('include', '/werkgever/uw-account');
});
when('recruiter has no products', () => {
cy.get('.product-item').contains('Je hebt nog geen producten aangeschaft.');
});
when('recruiter selects a profile', () => {
cy.visit('/recruiter/kandidaten/zoeken');
cy.get(':nth-child(1) > .search-result').click();
}); it is not able to download |
Hey @Akshaya0309, is there anything printed in the console when opening the |
@Akshaya0309 I hope the recording key is not real |
@Akshaya0309 Even after editing the comment, the key still shown in the edit history. |
Thanks I have deleted the history and update again. |
related: #1039 |
Getting the same issue. Cypress 3.1.0 - running headless Electron 59 One thing to note is this only occurs when i'm pointing my cypress baseUrl to a non localhost site. ie: my tests all pass when running my app locally but intermittent failure when running against dev/production environments. At first I discovered certain 3rd party scripts were blocking the page load event that I added to the blocklists in cypress json. This fixed those issues but I have little insight when running headless via network tools to diagnose the issue. Like others, I can't reproduce a particular test because sometimes they pass and others fail and vice versa. |
We are also non local. My plan - see if I can reproduce locally, not in the ci, then hack navigation.coffee to log things and show them on the screen so that the error screenshot tells me what’s wrong - because I’ve never seen this with the ui open |
@acSpock can you check in your network timeline if you can see the same issue as this with your blacklist: #1039 (comment) |
@mattvb91 is there a way to check this in headless electron with logs? I'm blind running in headless. Update::: I'm able to get around this error by updating |
This is great @maxime1992, I'll start digging in. Do you have the entire log by any chance? |
@flotwig yes, here's the full log |
I have the exact same issue as @maxime1992 When upgrading from 3.2.0 to 3.3.+ one of my tests timeout with this error message Let me know if you need further debug logs. Thanks |
I'm getting the same thing too. I increased the timeout as well with no luck. Here are my logs: |
Hmm, I was hoping 3.3.2 would fix this issue but doesn't look like it. @lou @zsalzbank Could you share the spec that reproduces this behavior? |
This is only happening for me on CI (CircleCI). Interestingly, if I SSH into the instance and then run the test with the same command, the test does run to completion. I'll try to come up with an example repo. |
describe('login page', function () {
beforeEach(function () {
cy.exec('RAILS_ENV=test bin/rake cypress:fixtures')
})
it('sets auth cookie when logging in via form submission', function () {
cy.visit('/users/login')
cy.get('input[name="user[email]"]').type('user@test.com')
cy.get('input[name="user[password]"]').type(`aloha42{enter}`)
cy.url().should('include', '/users')
cy.getCookie('_test_session').should('exist')
})
}) FYI I have the exact same kind of tests (same code) for two other kind of users and these 2 tests work as expected. |
So for me, it seems that this was an issue with loading resources on the page. I am testing a react application, and the first request to the page will compile the JS bundle. The first request was always taking much longer than the initial timeout since it is a large application. Subsequent attempts succeed (on the same machine) because the initial request already started the build process. It seems like it might be helpful for the error message to indicate that there were still some resources loading if the visit doesn't succeed because of resources (and maybe what the resources were). My page itself was loading from the server, but the load event was what wasn't triggering. I realize that the error message indicates that for the most part, but more details would probably help. |
I'm having exactly the same problem. Blacklisting does not behave as expected (issue), which leads to flaky tests, which leads to team distrust. |
Giving my experience with this issue, maybe it helps some people. For us this was caused by some occasional Exception that was visible only in the console, and this exception was caused by a race condition in our code, which in turn was caused, as far as i can tell, from a smaller number of simultaneous network connections in cypress's Chrome and Electron. |
I have the same problem, and intercepting
|
It looks like 3.3.2 did resolve this for us |
This is happening 100% of the time on a particular page for us. This only seems to happen when when the page requests confirmation to navigate away. Hoping this helps with the diagnosis This only happens in Electron not Chrome. |
This seems like the right "fix", went from tests working fine yesterday to completely failing this morning. The moment I update from 3.3.1 to 3.3.2, everything works. Madness. |
I was experiencing similar intermittent My tests visit the login screen at the beginning of each test but in some instances the "user" was staying logged in (I only realised this after repeatedly running an entire test suite using I was able to solve the issue by dispatching an existing redux My issue is probably different to the one described above but I thought I'd share my solution in case it helps anyone else who experiences a similar issue and lands on this ticket. |
Noticing the same undesired(?) behaviour as @mattcrooks has referenced:
while running Electron 61, on
Update: My current understanding is that, in my particular scenario, Cypress sometimes thinks a test keeps running when there are continuous (BrowserChannel, in this case) long-polling requests. Don't know if this is by design. Maybe somebody from @cypress-io can comment in that? As a workaround, the strategy on our end is to end those requests so that Cypress can fully complete the specific tests. |
Known
|
I am also facing the same issue. Launching browser is working fine. When I am clicking the "View more market link". it is throwing "CypressError: cy.visit() failed trying to load:" My code is below: describe('My firs Test',()=> {
it('load page',()=>{
cy.visit("https://www.binance.com/en")
cy.xpath("//a[text()='View more markets']").click();
cy.wait(50000);
})
}) Getting the below error:
|
I don't think so. The live domain you are testing returns the Cypress uses an iframe to load tests. IMHO you will not be able to test this page in Cypress, unless you are able to modify the return headers and/or use a non-live version of the page, which is normally the better option anyway. |
This issue is giving us random build failures on random tests. This does not happen very often - maybe once every 30 builds (more often when the infrastructure is under heavy load). On the video the page is loaded normally, the XHRs have completed - it just stays at cy.visit step and eventually fails with Would it be possible to catch this and re-execute the test? |
@drewbrend great pick up. Was using the same approach but you're right about the intermittent issue when using |
@jennifer-shehane The same issue occurs to me more often. Is there a way to capture the error and visit the page again? |
Experiencing the same issue but the strange thing is that the tests are all running fine locally but on CI it fails every single time. |
@pratik-chakravorty try setting --ipc=host if you're Docker, that will resolve the issue. If Kubernetes create a pod with spec hostIPC: true. If not both, can you be specific what's your CI comprises of? |
@RashmiKalpeshChauhan I'm not able to reproduce this issue in 3.8.3, please try upgrading. We will be closing this issue. There is one known issue provided in this long thread which is related to #2118 - If you have an Every single other mention of this issue happening has not provided a reproducible example so we have no path forward to investigate. If you are seeing the exact same error as below:
|
Current behavior:
99+% of the time this is not an issue, but once in a while the
cy.visit()
at the beginning of a test will not load the page, no matter how long of a timeout I set, no XHR requests are sent, nothing is loaded in the page. This is only ever seen in cypress tests and has never been seen manually by our testers so I am sure it is a bug with Cypress.Desired behavior:
Always load the page.
Steps to reproduce: (app code and test code)
I realize I am not providing a reproducible example, but it is not triggered by any specific test and is not reliably reproducible. I have seen in other tickets that members of the cypress team have asked for additional logging to be turned on. I would like to turn on additional logging that may help diagnose this and provide you the logs next time this happens.
Versions
Cypress 3.1.3
The text was updated successfully, but these errors were encountered: