Ajax request from previous test runs in the next test

[bahmutov]

We have noticed a weird problem.

One of our tests has a POST request that has not finished yet, but instead runs in the next test (even before login, thus failing). I am attaching the screenshot. Notice the POST 403 to /statsbox/metadata url - this is part of the previous successful test "scores a study ..."

Also, notice that this POST happens just as the test loads the login page, thus the POST gets CSRF 403 error.

[bahmutov]

just saw this issue with 0.17.4

[brian-mann]

This is part of a larger problem in Cypress which we've been aware of for awhile and we intend to fix.

The problem is that there is no real 'enforcement' of clearing state between tests. It is only lazily enforced during a cy.visit, which is really controlled by your own test code and not Cypress itself.

What is happening here is that until the browser processes the subsequent cy.visit on test #2, the previous test still has it's window and everything in javascript is still being processed, naturally including XHR's and setTimeouts and anything else.

We do actually attempt to enforce aborting currently running XHR's, but that is not a real solution because XHR's could be shot off asynchronously or "after" the period of time we attempted to abort currently running XHR's.

Because of this its possible those actions can "leak" into subsequent tests until a cy.visit finishes which at that point nukes the previous window altogether.

The problem is further complicated because we do enforce things like clearCookes and clearLocalStorage but we don't enforce clearing application state.

However, this is what we intend to fix. We're going to be specifically forcing the destruction of the previous window before we begin processing subsequent tests. That is easy enough, but we wanted to make it clear that we're doing this, and also give you (an API) for potentially turning off these lifecycle events.

We're also going to be adding a new instrument panel in the command log that describes the exact actions Cypress took prior to running your test code that went towards the teardown and state reset of the previous window.

There's going to be new configuration options in cypress.json that will look something like this by default:

lifecycle: {
  abortXhrs: true,
  teardownPage: true,
  clearLocalStorage: true,
  clearCookies: true
}

So those will be the default 4 things we'll always enforce between tests unless you explicitly turn them off.

[bahmutov]

awesome, thanks for clarifying this. It is not a major issue I feel, and we can get around by waiting for XHR requests to finish for example for now, or just plainly add time outs using afterEach

[romelperez]

Currently I have some AJAX requests which depends on some localStorage data. Isn't there a way to prevent Cypress from clearing up my localStorage before each test? Or is there a workaround? I would like to control it myself.

[dipunm]

Hey guys, I have been encountering this issue myself, I was wondering if there was a good workaround that doesn't rely on waiting for the xhr response, maybe running cy.visit() after each test?

I looked at the documentation, it seems this configuration proposal is not net implemented?

I look forward to your responses.

Thanks.

edit: the cy.visit() idea didn't work.

[jennifer-shehane]

There generally are ways to hack around these issues, just wanted to note that the real fix for this from Cypress is detailed in our Lifecycle Events proposal: #686

[jennifer-shehane]

Closing in favor of #686

[fedxgibson]

What worked for us was to add an after hook, and run a .visit('/') command.
As @brian-mann mentioned:

What is happening here is that until the browser processes the subsequent cy.visit on test #2, the previous test still has it's window and everything in javascript is still being processed, naturally including XHR's and setTimeouts and anything else.