Cypress: Cypress doesn't always clean up cookies

[verheyenkoen]

Current behavior:

We have a test that checks if an unauthorized user is redirected to the login page when directly visiting a URL to the "backend" site. This test occasionally fails. From the screenshot it is clear that the user was just sent to the specific backend page without login.

I checked (console props of the cy.visit command & cy.getCookies + cy.writeFile) and in some cases the auth cookie from the previous test is not cleared. For that I'm using a custom login command that only fetches cookies once (per username) and stores them in the global scope. Then I use cy.setCookie() to set the cookie again.

In this case the cookie was set in the beforeEach hook of the previous test.

Obviously this never fails if I just run the latter spec.

Desired behavior:

Obviously, by default (unless Cypress.Cookies.preserveOnce() is used), all cookies should be cleared before a test run starts.

How to reproduce:

This is hard. I couldn't narrow it down to one specific always-reproducable scenario but these are things I can confidently say about it:

• I've seen it fail multiple times in headless runs
• I've seen it fail multiple times in headed runs (cypress run --headed)
• I've seen this fail one time in the UI (cypress open)
• I've seen it fail in all 3 browsers in headed runs

I'm not sure but it seems to fail easier if I change the focus to other apps (or spaces) while running the tests, but even that isn't deterministic for me.

• Operating System: Mac OS X Sierra
• Cypress Version: 1.0.2
• Browser Version: All

[verheyenkoen]

I simplified my login command (because it also produced an application specific side effect and didn't really turn out to save much time), just keeping the cy.request statement and not storing cookies anymore and the problem is still there so it's probably not related to cy.setCookie.

[brian-mann]

Do you think this is related to this issue? https://github.com/cypress-io/cypress/issues/408

[verheyenkoen]

@brian-mann I checked that one. It's not a cross-domain login so I guess not. Am I right that I should never manually call clearCookies in an after hook?

[brian-mann]

Correct, Cypress automatically clears cookies prior to each test.

You can use the cookie debug API to print every single modification to every single cookie.

https://docs.cypress.io/api/cypress-api/cookies.html#Debug

[verheyenkoen]

Is there any way to dump the command log of a cypress run (apart from video recording). Cypress.Cookies.debug() may lead me to the problem indeed but this one is very hard to reproduce in the UI, so I'm looking for a way to review these cookie changes.

[brian-mann]

https://github.com/cypress-io/cypress/issues/700
https://github.com/cypress-io/cypress/issues/448

[pawelgalazka]

Can confirm, Cypress does not clear the cookies between tests, it let it leaks. This not happens all the time though.

[webdevian]

We are having this problem intermittently on Mac OS X Sierra w/ Chrome 63 and Electron 53 on the first test in our spec.

Printing out cy.getCookies() appears to show the cookies are cleared between tests but when we print out the request cookies in php there are some cookies there.

It has been hard to replicate this, there doesn't seem to be a pattern to force it to happen.

[verheyenkoen]

On my end also the first test in the spec that fails. Obviously only if other specs have been run before.

[antonfisher]

In my case it was silly, I had whitelist configuration to keep session id between different cy.location() calls and I forgot about it:

Cypress.Cookies.defaults({whitelist: 'sid'});

So I need to clean up this particular cookie before run whole test spec: before(() => cy.clearCookie('sid'));.
Just in case.

[verheyenkoen]

I'm not using that feature so that's not it.

[webdevian]

Any luck with v2?

[verheyenkoen]

Didn't see this fail anymore. Were there any changes on this part?

[webdevian]

I have noticed it happen still

[verheyenkoen]

Ok now I have too.

[lukemadera]

I'm having this issue as well.

[djalmaoliveira]

I have some problem with cookies/session, my workaround was first select "electron" and run tests that will not work properly, after that select "Chrome" and run tests that work.

Cypress package version: 2.1.0
Cypress binary version: 2.1.0
OS: Ubuntu 17.10

[anurbol]

I have the problem too, cookies persist. That means I am always logged in and my login test fails. Problem is on both Windows 7 and Linux (Debian 9.4), in Chrome, Cypress 2.1.0.

Can this be an issue of Chrome?

I noticed some interesting pattern: cookies are cleared as expected, when I:
1) cypress open
2) run all tests
3) (old cookies are there, user is logged in) stop tests by clicking stop button
4) F12 (open DevTools)
5) restart tests -> everything is OK

[scrat98]

the same problem

[kc-beard]

same problem. cookies are persisting.

[anurbol]

My temporary workaround:

describe('Auth', function () {

    before(() => {

        // remove this when issue will be solved
        // https://github.com/cypress-io/cypress/issues/781
        cy.visit('/')
        cy.clearCookies()
        cy.reload()
    })

...

Place this code at the very beginning of your tests (I guess they are ordered alphabetically).

[kc-beard]

@anurbol we went with something similar, but we have several describe blocks across different files so it's a pain to have to do this everywhere.

[verheyenkoen]

@kc-beard You can also define a beforeEach routine in your support/index.js file, which would be executed before each test in any other file, but that's probably overkill...

[kc-beard]

@verheyenkoen thanks for the tip! I didn't know that. Seems like that's covered in the docs too but i missed it (https://docs.cypress.io/guides/core-concepts/writing-and-organizing-tests.html#Support-file)

[anurbol]

@kc-beard in my experience, placing this in one file (which is starting point of your tests) is enough. verheyenkoen's answer is 2nd option, but as said, overkill (slows down tests execution significally).

[KrisBraun]

This is definitely a significant issue! Feel like something that requires warnings in the docs until it's resolved, as it took us a while to figure out why tests were failing when the documentation claims that cookies are cleared between tests.

[GrayedFox]

I can consistently reproduce this. After experimenting with persisting cookies using the whitelist feature and trying various setups, here is a summary of information about my current setup which consistently reproduces this issue:

• don't persist cookies using whitelist (not needed to exhibit bug)
• only two sets of integration tests, with the first one run always being the login tests
• in the second set of integration tests don't attempt to login anywhere (using browser, or cy.request)
• in the second set of integration tests, in your beforeEach block, attempt to visit a page on your app that requires auth

If you run all specs with:

cypress run  // or in my case, yarn cypress run

The second set of integration tests will pass.

If you run the tests separately with:

yarn cypress run --spec 'cypress/integration/auth/**/*'
yarn cypress run --spec 'cypress/integration/secondSet/**/*'

All tests will pass in the first run, and the second set will fail, due to being unauthenticated.

[GrayedFox]

I understand this bug was opened in October 2017, but could we get some confirmation that this is indeed a high priority issue? I'm trying to convince a rather large Ruby team using Rspec to move over to Cypress and with inconsistent cookie handling, there's simply no way we can start integrating this into our CI and start replacing the old (flaky) Ruby tests.

Love the work and philosophy behind Cypress but it is sometimes a bit hard to see what is actively being worked on and what is a priority. If this really is something which still "needs investigating" after the amount of user reproductions, I'm not sure I can convince my team this really is the right choice for us at the moment :confused: (I may be assuming too much of that label!)

[KrisBraun]

We're in exactly the same position. Ready to make a big investment in Cyprus (including becoming a paying customer), but this is the biggest blocker for us. The length of time and lack of communication is giving us second thoughts.

[nirpeled]

Was this fixed in v3?

[kc-beard]

@jennifer-shehane this is #781, assuming there's another issue you meant to link. In our case, they are on a separate domain.

@nirpeled no, we are seeing the same issue in v3

[jennifer-shehane]

Sorry, I meant duplicate of https://github.com/cypress-io/cypress/issues/408

[verheyenkoen]

@jennifer-shehane This was already suggested by @brian-mann last year (see earlier in this issue).

Do you think this is related to this issue? #408

My reply back then was:

@brian-mann I checked that one. It's not a cross-domain login so I guess not. Am I right that I should never manually call clearCookies in an after hook?

[dwelle]

In my case the cookie is not only not cleared on a cold run, but also the cookie with new value is being overriden by the old value (i.e. the cookies are set 2x on a cold run -- 1st the new value, 2nd the old value from previous test). The test must be restarted for the cookie to be set properly.

Is this the same issue and can somebody reproduce this, or should I create a new one?

Edit: I've narrowed it down --- the cy.visit() sets its own cookies for some reason, and it uses the previous cookie (which was supposed to have been cleared), so that's why it overrides the cy.setCookie() that I issue before the cy.visit(). This happens only on a cold run, as stated above.

[dwelle]

Ok, 4 hours later of trying to write my own cookie layer on top of Cypress, it's now obvious where's the flake from cold run coming from:

1. cypress on cold run opens a browser and visits http://localhost:53814 (or something like that) which is its own domain.
2. you run cy.clearCookies() (well you don't have to since Cypress does it before eachh test) in a before() hook in your index.js, and it clears the cookie from that domain, not your own.
3. you then run cy.visit('your.domain/'), and it has the cookies from your previous run --- provided you didn't run cy.clearCookies() in an after() hook - use of which is usually discouraged because after() isn't guaranteed to run (which is why we didn't do that).

Thus, until https://github.com/cypress-io/cypress/issues/408 is implemented, the only way to solve this (without hacks such as recovering from flake and running cy.visit() twice) is to put cy.clearCookies() in the after() hook in index.js.

EDIT (18-11-18):

The main issue is this: on a cold run, setting an initial cookie before the first cy.visit will set a cookie with domain of the cypress runner's empty page (localhost on a random port), and that cookie won't be sent alongside the cy.visit request to your server. This can be fixed and automated away using this code (adapt for your purposes):

// cypress/support/index.js

Cypress.Commands.overwrite( 'setCookie', (origFn, name, value, opts) => {
    return origFn(name, value, {
        domain: '.' + new URL(Cypress.config('baseUrl')).hostname,
        ...opts
    });
});

before(() => {
    Cypress.config('baseUrl', 'http://your-app.test');
});

[jennifer-shehane]

Can anyone else confirm @dwelle's workaround solves your issue?

[verheyenkoen]

I think I get the reasoning of @dwelle but I don't understand why this bug is not consistently reproducible then.

Also, the proposed solution will not work in projects where you visit pages on multiple domains I guess.

It could be a solution for Cypress to not do the "localhost + random port" thing at all when a baseUrl is configured and instead use that baseUrl from the start of each session, so the cookie problem cannot occur anyhow (given that @dwelle's findings are correct and you're working in a "single-baseUrl-project").

[dwelle]

There's more to it than that. From what I remember, when the cold run encounters cy.visit it restarts the test so that any commands before it (such as cy.setCookie) are re-run on the correct domain and in AUT env --- which in itself should fix the problem my code above is aiming to solve --- but it doesn't. There's some bug which makes the cy.setCookie not override the cookie from previous run (at least cy.visit doesn't use the new cookie). I'm probably not making a lot of sense right now -- I'll investigate more, later, and prob create a new issue since it seems somewhat different from this one.

[verheyenkoen]

@dwelle Did you check #408? From the description that one seems different but the underlying problem (and fix) could be the same.

[dwelle]

@verheyenkoen yep, I first thought #408 would fix this (and it still might), but I wanted to investigate further if there aren't deeper problems.

[jennifer-shehane]

It could be a solution for Cypress to not do the "localhost + random port" thing at all when a baseUrl is configured and instead use that baseUrl from the start of each session, so the cookie problem cannot occur anyhow (given that @dwelle's findings are correct and you're working in a "single-baseUrl-project").

This is the behavior of Cypress today. If you have a baseUrl set, we do not visit the localhost + random port and instead visit the configured baseUrl.

[verheyenkoen]

@jennifer-shehane I know but does cy.setCookie() also use the same domain from the baseUrl (before the first cy.visit() command is called)?

[dwelle]

@jennifer-shehane This is the behavior of Cypress today. If you have a baseUrl set, we do not visit the localhost + random port and instead visit the configured baseUrl.

Huh... didn't think of that --- note that it only behaves like that if the baseUrl is set in cypress.json, and it seems to solve the issue I was describing above.

But, doesn't work if the baseUrl is set in support/index.js's before() which is what I've been doing all the time for some reason.

Edit: which makes sense, reading Cypress.config and Setting a global baseUrl.

[benmcgarvey]

We have set the baseurl in cypress.json and still see this behaviour erratically. The behaviour only occurs when doing a login with cy.request, it doesn't appear to properly set the cookies and the previous cookies are used? See screenshots for reproduction. Note original cookie used in second test only after visiting a new address.

First user test screenshot

Second user test screenshot

Example done with something similar to below:

// log cookies here
cy.request({
  method: 'POST',
  url: '/account/login',
  followRedirect: false,
  form: true,
  body: {
    email: user.email,
    password: user.password
  }
}).then((resp) => {
  cy.visit(resp.redirectedToUrl);
});

// log cookies here
cy.visit('/home')

// log cookies here

[Bobgy]

Hi, I've been experiencing intermittent test failures related to cookie, when I run them sequentially in either cypress open or cypress run.
I haven't yet to find any way to stably reproduce them.

However, later I met another issue with webapp from previous test interacting with setting local storage in the next test. So I applied this hack to clear previous webapp: https://github.com/cypress-io/cypress/issues/686#issuecomment-443691052

beforeEach(() => cy.visit('/some-blank-page-that-has-nothing'))

Surprisingly, it not only fixed the local storage event handler issue, but also fixed intermittent failures related to cookies.
Now I'm guessing this may be related to previous app's lingering network requests interfering with our approach to clear all cookies.

[verheyenkoen]

@Bobgy That approach forces the baseUrl to be used from the very start of the test run which adds to the theory that Cypress may still use the "localhost:{random port}" base url for working with cookies (or local storage) until the first cy.visit or cy.request is recorded, which is clearly wrong.

I guess doing cy.request('/some-blank-page-that-has-nothing') would yield the same results. Can you try as that may be better in terms of performance?

[Bobgy]

@verheyenkoen The primary reason I do that is because of needing to clear the app from previous test. So using a request couldn't fit my need.

Secondly, I have a correct global baseUrl setup which is the same as the domain I test, so I don't think that's how it went wrong.

Thirdly, the intermittent failure never happen in the first test, so it seems to be related to previous test, not initial state

[DennisLoska]

too bad this issue still exist, just stumbled upon it today. The workaround to visit a page, clear the cookies and then reload again works though.

[andreasmihm]

same issue here with cypress 3.1.5.
our setup is:

• testing angular 5 frontend
• most tests which start with login
• cypress open -> run all tests : no problems
• cypress run -> all tests against localhost (http) : no problems
• cypress run -> all tests against dev system with https : after some successful specs the login stops to work, because there is still the access_token cookie from previous spec run available, all other test specs with login then fail

• with the fix proposed by @anurbol we can work around the problem

This is an absolutely essential issue, don't understand, why the bug is still open

[rj-david]

We are facing this random problem of cookies not being cleared properly for the last few months now. The fixes proposed in this thread did not consistently solve the issue for us.

Accidentally, seems like we found something working for us. After clearing the cookies, we get the cookies and check if it is empty.

cy.clearCookies();
cy.getCookies().should('be.empty');

[rbrondgeest]

The issue narrows down to the following:

• Cypress visits the baseUrl in your cypress config.
• If you didnt provide a baseurl it will visit localhost with a random port.
• It clears cookies, sessionStorage, localStorage etc. on this domain.

Cookies are scoped per domain name. If your test spans over multiple domains cookies will NOT be removed on all of these.

This will result in your tests being really flaky, especially since your tests do not necessarily always run in the same order, and therefore different cookies will influence each other.

I am not sure if this should be considered a bug. Cypress doesn't know which cookies in your browser are part of the test. This is how the browser operates.

So, bottomline:

Single host test:
Set your baseUrl

Multi host test:
Clear all cookies yourself by visiting each host that is going to be consulted in your test and calling clearCookies

[maksimkarpov]

my observation is that when tests are in the same file then everything is cleared after each test. If there are multiple js specs then the cache and cookies are not cleared (almost always), even by .clearCookies()

[dbnapp]

We were having some cookie problems of our own so I thought I'd share this solution that we've found. It may not fix everyone's problem, but our problem was that cookies were persisting when switching between tests. This caused network calls to start failing randomly because the request headers would be inflated with cookies.

Our fix was to open the cypress chrome browser settings and change the settings (chrome://settings/content/cookies) and turn on "Keep local data only until you quit your browser"

This setting should stay even when you rerun cypress

[DennisLoska]

@dbnapp Is it possible to try that solution in the cypress module api (headless mode)?

[vedmant]

I also have this problem. Looks like cy.clearCookies() does't clear cookies that are added to whitelist and you need to clear that cookies specifically for each cookie: cy.clearCookie('') which is not mentioned anywhere in documentation.

[j-mcgregor]

We were having a similar with handling auth cookies when spinning up the tests for the first time. It was because we hadn't set a "baseUrl":"http://your_base_url" in the _cypress.json_ which causes the browser to reload at the very beginning and sending us a different cookie. Once you've set a baseUrl you can visit the homepage with cy.visit(Cypress.config().baseUrl) and sub-domains with cy.visit('/subdomain').

[sekunda]

In my case it also happens nondeterministically that login cookies are not cleared between sessions, resulting with landing in the already authenticated page where it is not desired.

I have tried to add clearing cookies before performing tests (cy.clearCookies()), didn't work;
then I checked the cookies by cy.getCookies() and found out that cookies are not modified at all even after login. Anyway, login does work so I assume that there is some other mechanism underneath 'cy.cookies' that works nevertheless cypress cookies are set or not.

Edit: Now I can see why, #2573 and https://github.com/cypress-io/cypress-documentation/issues/1034, I think cy.getCookies returns only cookies from current domain, so when you use external service for authorization it seems to not always clear cookies from there..

[daniel-kun]

I observed a reproducible behaviour that when creating cookies in the browser session that runs the tests, then closing that browser and running that test from the Cypress UI's " Test" tab, the cookies from the just-closed browsers still exist.

Steps to reproduce:
1) Save this test to a file and run it from the Cypress UI:

describe("Visiting IFTTT", function() {
    it("should ignore the occuring JavaScript error", function() {
        cy.visit("https://ifttt.com/");
        cy.get('a.sign-in').click();
    });
});

2) In the browser window that is left open, log in to IFTTT (you can create a free account)
3) Close the browser window
4) Double-click the test in the Cypress UI again

Result:
When the test starts, you are still logged in

Expected Result:
You are not logged in

When rerunning the test inside the test runner browser window, it starts with cleared cookies and you are logged out.

Here is a video starting at step 2) showing the unexpected behaviour:
https://1drv.ms/v/s!AiPF014W0FYfv8cZyEaOpqlGqnQ2Dg?e=cis428

[smmdd]

I also have this issue in Test Runner. For tests on the same file, having different accounts to login on different tests doesn't cause any issue.
However, having different accounts to login on different files, will not clear the previous file cookies.

[justinanastos]

This issue celebrated it's second birthday yesterday and the third birthday for the related issue #408 is a few months away. Is there anything we can to do help? Is Cypress still being supported?

[MadLittleMods]

We just got bit hard by this, https://gitlab.com/gitlab-org/gitter/webapp/merge_requests/1657 (larger issue around our Cypress CI failures)

The hack from @anurbol seems to be working (thanks for sharing!). First e2e test pass in CI we have seen in a long time :tada:

[OdysseyQA]

I am still facing this, it is writing the previous test case result in my file , even though I am clearing the value for end of the execution

[mkstix6]

_I think this has all been suggested before but wanted to share just in case it helps someone._

---

My experience with leaky cookies seems to depend on how I'm running Cypress [[email protected]].
I am using the Nuxt.js (Vue.js) framework so perhaps there are some unforeseen interactions between Cypress' two different modes and Nuxt's Server Side Rendering + rehydration.

In GUI mode cypress open:

• my test passes.
• suggests the cookies are being cleared correctly between tests.
• can see the test running correctly in the browser.

In CI mode cypress run:

• my test fails.
• suggests cookies are not cleared correctly between tests.
• can see the test failing, consistent with uncleared cookies, in the generated video.

---

Using the fix provided by others above seems to clear the problem up for me.

_[Edit 20/12/2019: unfortunately I have found that this doesn't solve the issue all the time, but the issue does occur a lot less frequently]_.

I've put it in a Cypress command for convenience. The cy.reload() part seems particularly important but that may be cutting through an issue to do with clearing Nuxt.js' state, rather than Cypress.

// cypress/support/commands.js

// remove this when issue will be solved
// https://github.com/cypress-io/cypress/issues/781
Cypress.Commands.add('reallyClearCookiesCypressIssue781', () => {
  cy.visit('/')
  cy.clearCookies()
  cy.reload()
})

// cypress/integration/file_name.spec.js

  it(`Test name`, () => {
    cy.reallyClearCookiesCypressIssue781()
    // rest of test that relies upon clear cookies…
  })

[bvdr]

And here is my workaround to clear cookies that are set using whitelist regex and set them again:

it("Clear browser cookies and localstorage", function(){

  //Visit URL
  const host_url = Cypress.env('host_url');
  cy.visit(host_url)

  // Empty defaults
  Cypress.Cookies.defaults({
    whitelist: []
  });

  //Clear localStrage
  cy.clearLocalStorage()

  //Clear Cookies
  cy.clearCookies()

  // Set defaults
  Cypress.Cookies.defaults({
    whitelist: /wordpress_.*|woocommerce_.*|wp_woocommerce_.*/
  })
})

[Naycon]

This is a long shot, but could this issue be caused by leftover XHR requests that contains set-cookie headers? Imagine test 1 completing whatever it is supposed to do and that you check that the page contains some string. The page fires some XHR requests to do some very important stuff. Meanwhile, Cypress moves on to the next test and goes about canceling the XHR requests and clearing cookies. Could it be that if we're unlucky, the leftover XHR request gets treated by the browser to the point where the set-cookie header is read and applied and that this somehow (asynchronously?) happens after the clearCookie command has run?

We experience the same issues as above, and none of the fixes seems to have worked. But I did notice a bunch of XHR requests being cancelled in my beforeEach step (where I clear cookies). I tried introducing a little delay before clearing the cookies, and all of a sudden all my tests started passing:

  beforeEach(() => {
    cy.wait(2000);
    cy.clearCookies();
    cy.visit('/');
  });

This theory would explain why this has been hard to reproduce in a simple isolated case, as you would need a sufficient bunch of XHR requests happening directly after page load and that all of the has a set-cookie header.

[VesterDe]

This is happening in between test files while running chrome, locally, headful for me. All tests in both files are on the same domain and subdomain.

When file #2 starts, it begins with trying /login and, since it has auth cookies set already, is redirected to /home in the app.

This is very consistent. I've solved it by running cy.clearCookies() before each login attempt.

[poponuts]

Same issue for me. The workaround cy.clearCookies({domain: null}) from https://github.com/cypress-io/cypress/issues/408 solved it for me locally. Haven't tried in CI.

[Jacek-fstack]

Any update on cleaning up lingering XHR requests from previous tests?

[estefafdez]

@rj-david I will try your approach, thank you for sharing :)

[Jacek-fstack]

@jennifer-shehane Are there any updates on this issue?

[GideonCS]

I'm also still running into this!

[pstephenwille]

I'm finding Cy will not delete cookies set with a max-age. At least not with simply clearCookies.
It does work when clearing each cookie by name.

```js
Cypress.Commands.add('clearMyCookies', () => {
myCookies.forEach(cook => cy.clearCookie(cook));
});

[Bobgy]

Any update on cleaning up lingering XHR requests from previous tests?

@Jacek-fstack did you see my workaround above?
https://github.com/cypress-io/cypress/issues/781#issuecomment-448977376

I thinking visiting a blank page is the best way to let browser clean up all lingering XHRs.

[jennifer-shehane]

We've outlined some work to be done to address some of the concerns of 'cookies' in this issue: https://github.com/cypress-io/cypress/issues/8301

It outlines a proposal for a 'session' API, to quickly summarize:

With cy.session, you'll be able to perform UI interactions before taking a "snapshot" of all the session related data and "restore" it before each test.

This session related data would include cookies.

I recommend reading the entire proposal in https://github.com/cypress-io/cypress/issues/8301 and following there for any updates. Please feel free to express any concerns or questions in that issue concerning the API and add a 👍 for general support.

[Hulkmaster]

can confirm that issue still is there in 4.12.1 (had it on 4.7.0, upgraded, but still have it)

rarely, but sometimes cypress does not delete cookies, and its completely random

[estefafdez]

I'm finding Cy will not delete cookies set with a max-age. At least not with simply clearCookies.
It does work when clearing each cookie by name.

 Cypress.Commands.add('clearMyCookies', () => {
    myCookies.forEach(cook => cy.clearCookie(cook));
});

@pstephenwille could you share what's myCookies is?

[javascripter]

Even on 5.0.0 cookies (and localStorage too?) sometimes leak between tests.
My workaround is like below. Waiting for cookies and localStorage to become empty seems to stabilize tests.

support/index.js

beforeEach(() => {
  cy.visit('/blank.html') // a blank html file in the same domain
  cy.clearCookies({ domain: null })
  cy.clearLocalStorage()
  cy.getCookies().should('be.empty')
  const getLocalStorage = (window) => window.localStorage
  cy.window().pipe(getLocalStorage).should('have.length.at.most', 1) // cypress seems to use localStorage in some cases so it can be 1
})

I now removed the workaround and simply retry tests using the retry functionality released in 5.0.0 though (confusing failed screenshots appear but this is faster).

[verheyenkoen]

Confirmed. Also still failing for me (only in headed mode).

plack_session is a sameSite strict cookie. This occurred in an afterEach hook btw.

I now tried cy.clearCookies({ domain: 'localhost' }) instead of cy.clearCookie('plack_session') which does consistently seem to work even though the 'domain' option is not documented anymore. Any other values I tried for domain (including null) also fails. The clearCookies command outputs this in the console:

[lugus]

Same for me, randomly fail, in headed or headless mode.

If i call cy.clearCookies() before my test, said it clears the PHPSESSID cookie, i cy.getCookies() => say 0 cookies but i always have my PHPSESSID cookie in the Application/Cookies panel in chrome console, so it doesn't delete correctly chrome cookies i think.

Clear cookies:

Get cookies:

Checking cookies in Chrome console:

[Jacek-fstack]

I'm getting the same thing in cypress 5.2
Even though I clear cookies SEVERAL TIMES in a row:

    cy.window().then((win) => {
        win.sessionStorage.clear()
    });
    cy.clearCookies({domain: null});
    cy.clearCookies();
    cy.getCookies().should('be.empty');
    cy.clearLocalStorage();

And a few times before the test separately etc.
The get cookies sometimes yields

 "before each" hook for "tests logging in with a new account admin user ":
     AssertionError: expected [ Array(2) ] to be empty

How can I log these cookies and see which ones fail to clear?
When running in headless or headed, not the "OPEN" mode, where I can obviously go to the console and look.

[badeball]

After having upgraded to v5.5.0 from v3.4.0 (big mistake), we've started experiencing not only cookies not being cleaned up, but also cookies leaking into requests towards other origins. Do you have any idea how much fuckery this is causing? How have you, Cypress, not experienced all these cookie-issues in your own test suite?

[badeball]

@jennifer-shehane

We've outlined some work to be done to address some of the concerns of 'cookies' in this issue: #8301

It outlines a proposal for a 'session' API, to quickly summarize:

With cy.session, you'll be able to perform UI interactions before taking a "snapshot" of all the session related data and "restore" it before each test.

This session related data would include cookies.

I recommend reading the entire proposal in #8301 and following there for any updates. Please feel free to express any concerns or questions in that issue concerning the API and add a +1 for general support.

Get out of here, that proposal doesn't address any of these concerns. Furthermore, how in the world do you expect to implement cookie-sessions successfully when you haven't even remotely succeeded with the current handling?

[badeball]

FYI, we're also seeing requests made by cy.request being repeated, but like everyone else here, we're experiencing it intermittently and are unable to create a minimal example that consistently reproduce the issue.

Edit: The above-mentioned request is a request where redirection is expected. The initial request is what's getting repeated, intermittently.

Edit2: I know requests are being repeated, because I'm looking at the ingress-logs of the service being requested, IE. I'm not relying on Cypress to provide me that information.