cypress: Cy.wait() sometimes returns an empty string request.body
Current behavior
I have simplified the problem to it’s bare bones and censored out any sensitive information.
(Referring to the Test Code) When submitting the form on our webpage, a request to urlA is expected to have the formdata from that submission in application/x-www-form-urlencoded format but randomly request.body is an empty string.
I am waiting on ‘@aliasA’ in order to be able to validate the payload of the request to urlA. Referring to Image A, I can see that Cypress is able to match the requests to my interceptions properly. The expected payload is available in the matched interception. I didn’t screenshot it but the network tab also reveals the same with the payload being available.
But on random occasions (often enough to warrant writing a bug about it), I will receive the error in Image B. When viewing the error in more details, I see “Error: Socket closed before finished writing response at…”.
Image A
Image B
Desired behavior
For the request.body to be available 100% of the time when waiting on the interception.
Test code to reproduce
beforeEach('setup event logs', () => {
// All of these intercepts are in support/e2e in real implementation and called here as Cypress commands
cy.intercept('POST', 'urlA', () => {
req.redirect('urlB', 302);
}).as('aliasA');
cy.intercept('GET', 'urlB', () => {
req.redirect('urlC', 302);
}).as('aliasB');
cy.intercept('GET', 'urlC', () => {
req.continue();
}).as('aliasC');
});
it('should have correct payloads', () => {
cy.get('form').submit();
cy.wait('@aliasA').then(({ request }) => {
cy.fixture('aliasAFixture.json').then((expectedPayload) => {
// request.body will sometimes return '' and fail the test
expect(request.body).deep.contains(expectedPayload);
});
});
cy.wait(['@aliasB', '@aliasC']);
...
});
Cypress Version
12.4.1 - 12.9.0
Node version
v14.17.3
Operating System
Windows 64-bit operating system Windows 10 Pro 22H2
Debug Logs
No response
Other
Other possible relevant information
- All of the intercepts used in the example are in the separate support/e2e.js (renamed to utils/interceptions.ts for my folder structure) in the real implementation and called in the
beforeEachas Cypress commands. - My Cypress project is in Typescript
- I use
@cypress/xpathand@faker-js/faker
Things I have tried
- Changing the req.redirect of aliasA to req.reply
- Added a delay of up to 1 second
- made followRedirect true and false
- req.headers[‘content-type’] = ‘application/x-www-form-urlencoded’ in case the request wasn’t reading the body properly
- Tried putting the assertion
expect(request.body).deep.contains(expectedPayload);inside the interception itself before and after thereq.redirect(). - Tried putting a 10 second timeout in the wait(‘@aliasA’) before accessing the fixture for the expected payload
- Tried singling out the assertion in the wait to be the only thing in the test
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 15 (11 by maintainers)
@romek-buildops We would review a PR to address this, our team is not currently prioritizing this.
I have the same issue on version v13.6.2
would be great to have it fixed. this struck us constantly with out runs…
Interestingly if I only run one test in that test file, I never get the error out of the 20 runs:
Details
Hi @SplikStick and sorry for the delayed response here. I am really curious about this and would love to reproduce it to debug. I feel like even with the information provided this is challenging to solve as it would involve speculating about places a race condition may be occurring that leads to this outcome X% of the time in your project.
If you are able to make something with https://github.com/cypress-io/cypress-test-tiny that reproduces this even rarely it would help.
Maybe running tests this way:
@mirobo it’s a good point that
Socket closed before ...is a good starting point and these may be related. In which case we should test this again when https://github.com/cypress-io/cypress/issues/26248 is worked on.If we are able to reproduce the behavior in this ticket I will forward it to the team as well.
This issue could be related to #26248 ?