-
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
cy.wait timeouts on aborted xhr requests #9549
cy.wait timeouts on aborted xhr requests #9549
Comments
I'm not able to reproduce the error with the provided code. It looks like in your screenshot you have a server running with some browser-sync requests - can you provide a full repo of the example? Something else may be involved outside of the example you gave. Please also try the newly released 6.1.0 as it has some intercept fixes. Test passes with only code provided above |
@jennifer-shehane indeed you are right, I'm also confirming the same behavior So whenever you are doing something like: But when we use something like: Unfortunately, 6.1.0 still has this issue As about repo, I bed that it will be reproduced with |
And not directly related to this issue, but cy.state('requests') is not having the requests intercepting by cy.intercept just like cy.route? There is another issue talking about it? |
@guilhermebruzzi Can you provide an example of the it('test cy.intercept()', () => {
cy.intercept('/users').as('getUrl')
cy.visit('https://example.com')
cy.window().then((win) => {
const xhr = new win.XMLHttpRequest()
xhr.open('GET', '/users')
xhr.send()
})
cy.wait('@getUrl').then(() => {
expect(cy.state('requests')).to.have.length(1)
})
}) Also, we'll need a reproducible example for the issue in this thread. Without that, the issue will need to be closed as we can't move forward with investigating. |
Right now there doesn't seem to be enough information to reproduce the problem on our end. We'll have to close this issue until we can reproduce it. This does not mean that your issue is not happening - it just means that we do not have a path to move forward. Please comment in this issue with a reproducible example and we will consider reopening the issue. Here are some tips for providing a Short, Self Contained, Correct, Example and our own Troubleshooting Cypress guide. |
hm, here you go: git clone https://github.com/mac2000/cypress-9549
cd cypress-9549
npm i
npm start
npm test repro.mp4 |
@mac2000 Nice. Thanks for this. Sometimes the first time I run this it passes, but on rerun it definitely fails.
<html>
<body>
<button onclick="bad()">bad</button>
<script>
function bad() {
let xhr = new XMLHttpRequest();
xhr.open("GET", "https://jsonplaceholder.typicode.com/todos/1");
xhr.responseType = "json";
xhr.send();
xhr.abort();
xhr = new XMLHttpRequest();
xhr.open("GET", "https://jsonplaceholder.typicode.com/todos/1");
xhr.responseType = "json";
xhr.send();
xhr.onload = () => {
document.body.innerHTML += "<pre>" + JSON.stringify(xhr.response) + "</pre>";
};
}
</script>
</body>
</html> it('should handle non-aborted requests', () => {
cy.intercept('https://jsonplaceholder.typicode.com/todos/1').as('xhr')
cy.visit('index.html')
cy.get('button').contains('good').click()
cy.get('pre').contains('delectus') // response body renders to page
// ✅ passes
cy.wait('@xhr')
})
it('cy.route should handle aborted requests', () => {
cy.server()
cy.route('https://jsonplaceholder.typicode.com/todos/1').as('xhr')
cy.visit('index.html')
cy.get('button').contains('good').click()
cy.get('pre').contains('delectus') // response body renders to page
// ✅ passes
cy.wait('@xhr')
})
it('cy.intercept should handle aborted requests', () => {
cy.intercept('https://jsonplaceholder.typicode.com/todos/1').as('xhr')
cy.visit('index.html')
cy.get('button').contains('bad').click()
cy.get('pre').contains('delectus') // response body renders to page
// ❗️ times out sometimes
cy.wait('@xhr')
}) |
@jennifer-shehane indeed and it seems that root cause here is this socket connection being involved, so whenever on page we have some socket activity it somehow brakes everything, probably can test it even without lite-server by just adding socket connection to a page, but still need some server for this |
There are minor errors in the reproducible example above:
The corrected example is below: index.html <!DOCTYPE html>
<html>
<head>
<title>demo</title>
</head>
<body>
<button onclick="good()">good</button>
<button onclick="bad()">bad</button>
<script>
function good() {
const xhr = new XMLHttpRequest();
xhr.open("GET", "https://jsonplaceholder.typicode.com/todos/1");
xhr.responseType = "json";
xhr.send();
xhr.onload = () => {
document.body.innerHTML += "<pre>" + JSON.stringify(xhr.response) + "</pre>";
};
}
function bad() {
let xhr = new XMLHttpRequest();
xhr.open("GET", "https://jsonplaceholder.typicode.com/todos/1");
xhr.responseType = "json";
xhr.send();
xhr.abort();
xhr = new XMLHttpRequest();
xhr.open("GET", "https://jsonplaceholder.typicode.com/todos/1");
xhr.responseType = "json";
xhr.send();
xhr.onload = () => {
document.body.innerHTML += "<pre>" + JSON.stringify(xhr.response) + "</pre>";
};
}
</script>
</body>
</html> test.js* it('should handle non-aborted requests', () => {
cy.intercept('https://jsonplaceholder.typicode.com/todos/1').as('xhr')
cy.visit('index.html')
cy.get('button').contains('good').click()
cy.get('pre').contains('delectus') // response body renders to page
// ✅ passes
cy.wait('@xhr')
})
it('cy.route should handle aborted requests', () => {
cy.server()
cy.route('https://jsonplaceholder.typicode.com/todos/1').as('xhr')
cy.visit('index.html')
cy.get('button').contains('bad').click()
cy.get('pre').contains('delectus') // response body renders to page
// ✅ passes
cy.wait('@xhr')
})
it('cy.intercept should handle aborted requests', () => {
cy.intercept('https://jsonplaceholder.typicode.com/todos/1').as('xhr')
cy.visit('index.html')
cy.get('button').contains('bad').click()
cy.get('pre').contains('delectus') // response body renders to page
// ❗️ times out sometimes
cy.wait('@xhr')
}) |
I can also reproduce this. Though it is flaky in my case since canceled requests don't always happen. But every time the canceled request does happen, cy.wait('@alias') definitely fails. I'm running 6.4.0 |
I had the same issue on my CI environment (failure ratio up to 25% - GitActions) and the workaround (a good one so far) that I did was:
Or The failure rate went to 0.4%. |
I added a failing reproducible test in https://github.com/cypress-io/cypress-example-recipes/tree/aborted-request-example // https://github.com/cypress-io/cypress/issues/9549
it('handles aborted requests', () => {
cy.intercept('https://jsonplaceholder.typicode.com/todos/1').as('aborted')
cy.get('#aborted-request').click()
cy.wait('@aborted', { timeout: 2000 })
cy.wait(1000)
cy.get('#aborted-request').click()
cy.wait('@aborted', { timeout: 2000 })
}) |
Does the PR from saintkhk fix the issue for Cypress, or is it just a PR to fix some tests that also demonstrate this behavior? |
Well it was meant to fix the issue, but I can still see the issue with it
…Sent from my iPhone
On Feb 17, 2021, at 13:08, Jason Fairchild ***@***.***> wrote:
Does the PR from saintkhk fix the issue for Cypress, or is it just a PR to fix some tests that also demonstrate this behavior?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
The code for this is done in cypress-io/cypress#14885, but has yet to be released. |
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
Current behavior
Whenever there is something like this in app (pseudo code):
and this in test:
cypress timeouts with an error
Timed out retrying: cy.wait() timed out waiting 30000ms for the 1st response to the route: xhr. No response ever occurred.
As you can see on screenshot:
Desired behavior
Page with app loads and works as expected, cypress should handle such cases as well
Test code to reproduce
index.html - aka our app
demo.spec.js
Versions
cypress - 6.0.1
node - 12.8.3
chrome - 87.0.4280.88
os - macos 11.0.1 (20B29)
ci provider - undefined
PS: not sure but it might be related to this PR which was made by @brian-mann
The text was updated successfully, but these errors were encountered: