POST request drops body sporadically

[FelixWhitefield]

Current behavior

Currently I have a POST request which sometimes drops its body, as when checking with the server it is making the request to the body is empty and the Content-Length is 0. This happens rarely, potentially 1 in 20 times when running the test locally and on our CI pipeline.

The POST request comes from the site I am trying to test, and is triggered when a button is clicked on a page. It should have a JSON body.

When running Cypress open with the developer tools open and looking at the request in the network tab, the request has the correct body. But when debugging the server, the request has no body.

I have turned on Cypress Debug logging and have found that when the request body is dropped, Cypress seems to create a proxied socket for the request. But when the request body gets to the server, this does not happen.

Logs (relating to the failed request)
Failure Logs - When the request body is dropped (No response from the server because it is being debugged and was stopped when the issue occurred):

cypress:server:remote-states getting remote state: { auth: null, origin: 'https://our-server', strategy: 'http', fileServer: null, domainName: 'our-server', props: { port: '443', protocol: 'https:', subdomain: null, domain: '', tld: 'our-server' } } for: https://our-server/web_url/api/w/d/p/e+47ms
...
cypress:network:agent addRequest called { isHttps: true, href: 'https://our-server/web_url/api/w/d/p/e' } +49ms
cypress:network:agent got family { family: undefined, href: 'https://our-server/web_url/api/w/d/p/e' } +0ms
cypress:network:agent Creating proxied socket for https://our-server/web_url/api/w/d/p/e through http://127.0.0.1:64253 +0ms
...
cypress:network:agent Proxy socket for https://our-server/web_url/api/w/d/p/e established +1ms

Success Logs - When the request body makes it to the server:

cypress:server:remote-states getting remote state: { auth: null, origin: 'https://our_server', strategy: 'http', fileServer: null, domainName: 'our_server', props: { port: '443', protocol: 'https:', subdomain: null, domain: '', tld: 'our_server' } } for: https://our-server/web_url/api/w/d/p/e +54ms
...
cypress:network:agent addRequest called { isHttps: true, href: 'https://our-server/web_url/api/w/d/p/e' } +49ms
cypress:network:agent got family { family: undefined, href: 'https://our-server/web_url/api/w/d/p/e' } +0ms
...
cypress:net-stubbing:server:intercept-response InterceptResponse { req: { url: '/web_url/api/w/d/p/e' }, request: undefined } +84ms
...
POST /web_url/api/w/d/p/e 200 842.990 ms - -

We do have cypress-ntlm-auth installed, as we use NTLM for our authentication - in case it could be that plugin causing the issue.

I am happy to provide more debug logging if the above does not suffice.

Desired behavior

Cypress should pass the request body through all the time

Test code to reproduce

I cannot reliable recreate the issue

Cypress Version

13.15.0

Node version

v20.11.1 on CI, v18.20.0 locally

Operating System

Windows 22631.4317 locally

Debug Logs

No response

Other

No response

[ryanthemanuel]

The proxied socket that you point out will only be created if the HTTPS_PROXY environment variable is set and the url that you're dealing successfully is honored by the logic in this dependency. Is it possible that there is a difference in how/what environment variables are set between the success and failure scenarios?

[FelixWhitefield]

Thank you for your reply.

The environment variables should be the same between the success and failure scenarios as they happen within the same cypress open session. I retry the test locally by clicking the retry button in the Cypress app.

When running the tests I am connected to a corporate VPN as the server hosting the site is in our corporate network and is not accessible otherwise. Could that be a factor into the issue?

[ryanthemanuel]

The corporate VPN could be part of the problem but hard to know for sure. Do you notice a pattern when you're in open mode? Does the first one fail and then a retry succeed or anything like that? Or is it sort of random?

Also, you mentioned cypress-ntlm-auth. I'm assuming that's required for your situation? It'd be nice to remove it and see if the problem still occurs, but if it's required I know that may not be an option.

[FelixWhitefield]

Apologies for the delay in my response. I would say that it's more likely to fail when I first open it, and then the more I retry it fails less and less to the point where it doesn't seem to fail anymore, until I restart open mode.

There is a way to remove cypress-ntlm-auth and test without it but it would take longer to set up. I will retest the current bug and see if it is still occurring, and if so I will work on removing the plugin and checking if the bug still happens.