Cypress: Problem cancelling XHRs from previous test

[AshMcConnell]

Current behavior:

Yep, there is an issue if you don't wait for all XHRs to finish after a test. When it tries to cancel the XHR it fails with the error: -

UnsubscriptionError: 1 errors occurred during unsubscription:
  1) TypeError: Cannot set property 'aborted' of undefined

if I do an explicit cy.wait(2000) or cy.wait('@myxhr') it works
note it's the following test that fails, not the one with the XHR

Desired behavior:

The XHR should be cancelled correctly before the next test starts

How to reproduce:

Have a longish running XHR fire at the end of one test and have a subsequent test.

Additional Info (images, stack traces, etc)

It seems to happen when I am faking a route failure (status 500) and then make another (non-faked) XHR (to report the error to a server). e.g.: -

cy.route({
  method: 'PUT',
  url: '/Endpoint/Id',
  status: 500,
  response: ''
}).as('saveStuff');

• Operating System: Ubuntu 16.04
• Cypress Version: 1.0.2
• Browser Version: Electron 53

[brian-mann]

Related to https://github.com/cypress-io/cypress/issues/686 and almost a duplicate, but I'll leave this open for now until I can confirm it is.

[Mende]

Same issue.
Cypress CLI: 0.13.1
Cypress App: 0.19.2
Electron 53
Mac OS X Sierra

[brian-mann]

We no longer abort XHR's in between tests.

This was actually fixed in 0.20.0 and I forgot to close this issue then.

[daniil-g-8sph]

@brian-mann I still have the problem in 1.0.3 (Chrome 62, Electron 53 in both)

cypress_runner.js:136633 TypeError: Cannot set property 'aborted' of undefined
    at XMLHttpRequest.XHR.abort (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:65539:23)
    at XMLHttpRequest.onReadyStateFn (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:65617:27)
From previous event:
    at run (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:61887:15)
    at Object.cy.(anonymous function) [as visit] (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:62107:11)
    at Context.runnable.fn (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:62238:20)
    at callFn (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:32092:21)
    at Test.Runnable.run (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:32085:7)
    at https://spb.tele2.ru/__cypress/runner/cypress_runner.js:65090:28
From previous event:
    at Object.onRunnableRun (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:65089:20)
    at $Cypress.action (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:60592:51)
    at Test.Runnable.run (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:64240:20)
    at Runner.runTest (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:32555:10)
    at https://spb.tele2.ru/__cypress/runner/cypress_runner.js:32661:12
    at next (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:32475:14)
    at https://spb.tele2.ru/__cypress/runner/cypress_runner.js:32485:7
    at next (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:32417:14)
    at https://spb.tele2.ru/__cypress/runner/cypress_runner.js:32453:5
    at timeslice (https://spb.tele2.ru/__cypress/runner/cypress_runner.js:27694:27)
logError @ cypress_runner.js:136633

[TopWebGhost]

I have the same problem

[wijwoj]

I'm getting these errors when calling visit on a new url after running over from one test spec file to the next.

Currently having to do something nasty like:

Cypress.on('uncaught:exception', (err, runnable) => {
    return err.message.indexOf('Cannot set property \'aborted\' of undefined') === -1
});

[tan-nhu]

I'm facing the same problem with cypress 1.4.1.

[ScottSpittle]

I'm also facing this issue with 1.4.1

[joshmccure]

Also facing this issue with 1.4.2

[shcallaway]

I am also experiencing this with 1.4.2. I am not making any requests or even repeating cy.visit at the beginning of each test. I also don't see any aborted XHRs in the Cypress sidebar or failed requests in the Chome Dev Tools.

[adrinr]

Having the same problem with 1.4.1. Did somebody find some workaround?

[dracos]

Just to add still happening for us in 2.1.0, we've added an extra cy.visit("/") to make sure whatever was in progress is aborted.

[rafaelchiti]

@dracos where did you add the cy.visist("/")? I'm trying all the combinations possible and still having issues. In my case I have pub nub configured in the app. I'm trying to 'disable it' but wondering if this should work out of the box. Just came from TestCafe and this seemed to work just fine, wondering how they handle it. Thanks!!

[dracos]

@rafaelchiti At the end of the test that caused the next test to fail, went for a 404 in the end. See the cleanUpXHR function in https://github.com/mysociety/fixmystreet/blob/ed6c2501/.cypress/cypress/integration/regressions.js - hope that's helpful.

[mparpaillon]

@brian-mann If you no longer abort XHRs between tests how come we all still get this error ? I'm using 2.1.0 and I keep having this problem. Thanks

[royston-c]

@rafaelchiti did you have any success with the PubNub long polling and Cypress? Some of the functionality i want to test is dependent on it so I don't really want to stub it out.

[rafaelchiti]

mm I managed to get it going but seemed a bit off the stuff I had to do. Let me share the example here. I followed what dracos suggested. Either way I didn't experiment much, after this I switched to Test Cafe (due to other company requirements).

My test would have this:

  beforeEach(() => {
    cy.visit(Cypress.env("yourAppUrl"));
  });

  afterEach(() => {
    cy.cleanUpXHR();
  });

my commands.js

Cypress.Commands.add("cleanUpXHR", function() {
  if (Cypress.env("run_all_suite")) {
    cy.visit(`${Cypress.env("yourAppUrl")}/404`, { failOnStatusCode: false });
  }

my make file for running them:

test-cypress-open:
    cd test/e2e && npx cypress open

test-cypress-run:
    cd test/e2e && npx cypress run --env run_all_suite=true

I only executed the clean up when running the whole suite. When working on 1 test with the visual debugger I didn't want that behavior to kick in, since that visual debugger is sort of meant for working on one test at a time (from what I understand) and not to run multiple tests.
I didn't try but that is the latest I found in my repo I think that was the solution that ended up working.

[StormPooper]

Also seeing this with 2.10, but the extra page visit after the tests only fixes it most of the time, plus it adds time to each test to visit the extra page.

[pperry-atlassian]

Same here. Similar to @rafaelchiti and @roy46, our app has long polling requests that will trigger this error on every spec. I didn't have any luck at all with an afterEach hook, so I had to add a command as the last step in every spec to route to a static 404 html page. It slows the suites down since every spec has to reload the page.

[StormPooper]

Still an issue with 3.0.1 too.

[jechlin]

I was getting this too but only on test failures, which made it very hard to debug. In my case it turned out to be through using:

this.retries(1)

in an attempt to get it to retry failing tests once... this is a mocha thing that turned out never worked anyway, but I accidentally left it in. This caused the problem... maybe related upgrading to 3.0.1 but I doubt it.

[jennifer-shehane]

@jechlin Yeah, there's an issue open requesting support for this.retries() https://github.com/cypress-io/cypress/issues/1313

[StormPooper]

Just to confirm, we're not using this.retries() in our tests and still seeing this, but that's worth checking for others.

[rogeliog]

We are having the same issue, has anyone found a workaround by any chance?

[StormPooper]

We're doing this (based on https://github.com/cypress-io/cypress/issues/761#issuecomment-352375786) in our support/index.js:

Cypress.on('uncaught:exception', hackToNotFailOnCancelledXHR);
Cypress.on('fail', hackToNotFailOnCancelledXHR);

function hackToNotFailOnCancelledXHR(err) {
    const realError =
        err.message.indexOf("Cannot set property 'aborted' of undefined") ===
        -1;
    if (realError) throw err;
    else console.error(err); // eslint-disable-line no-console
}

Had to catch it in fail too since it doesn't seem to treat it as an uncaught exception from your own tests. It's still not great as it means if something fails for the same reason it'll assume everything's fine, but we've found it better than loading another page after each test.

[rogeliog]

@StormPooper This is great, thanks a lot!

[ronlawrence3]

I wasted a ton of time on various different test failures, thinking that cypress was being flaky on simple things like "get" or "click" or something causing application state to change unexpectedly. I noticed some "aborted" XHR calls in the logs, and I thought it odd, but didn't think it was related.

Then, I found this issue and added a cy.wait(2000) to my afterEach function to work around this and all my tests are working fine now! FRUSTRATING!

I'm also very concerned that when I run this in CI where latency increases that 2000 won't be enough.I HATE "sleep" in tests!

[green-arrow]

Just to add another scenario, we have PubNub integration in our application, which does a heartbeat XHR call at set intervals. This causes our tests to fail because the heartbeat occurs close to the end of the test and causes the next one to fail.

Using the solution from @StormPooper for now.

EDIT: I used the hack, however it causes my second test to hang up and never complete. If I disable PubNub integration and take away the heartbeat requests, both tests run successfully. This is an issue because it means I currently am not able to use Cypress to test my application at all.

[amenk]

We have the same problem when testing Magento 2 login where Chrome seems to cancel some requests, because the next page is loaded to quickly.

We now workaround it also with spreading some "waits" at tactical places.

I am wondering if those canceled requests are even a failure condition and maybe should be handled in a way to not abort the test, because, what's the problem with navigating fast?

Or could we add a function "wait for all XHRs to complete" ?

[nikosdouvlis]

We're facing the same problem with 3.1.0.

Sadly @StormPooper's hack doesn't seem to work for us.

[amenk]

Are there any ideas how to fix this?

[tonykaram1993]

Is this issue still present? Cause I am getting "Cannot set property 'aborted' of undefined" every 4th test or so, and each time in a totally different part of the test.

This is the error, im guessing it has something to do with aborting xhrs? That's what i think it is at least after what I have read in this thread.

I have wasted a lot of time on this, is there no solution to this yet?

[amenk]

@tonykaram1993 do you see aborted requests in the network tab in those cases?

[tonykaram1993]

@amenk I do, but im not sure if these are directly related to the issue. They don't happen right before the test fails, but I do see them a good 4-5 times during the entire tests (even when the test passes - test passes 75% of the time)

EDIT: Should have said, those are the ones that show in the cypress UI

[amenk]

Are you maybe able to construct a minimal reproducible example? If it happens every forth try you might add some 20x loop to make it almost 100% failing

[tonykaram1993]

I am quite busy busy this week, will try to make a reproducible example when i can.

[mlc-mlapis]

... isn't it the same problem as https://github.com/cypress-io/cypress/issues/1652 in fact?

[green-arrow]

I'm not sure if I have time this week either, but this kind of problem should be reproducible if you run a network call on a setInterval in the page being tested.

[StormPooper]

Can confirm this is still an issue on 3.1.0.

I had some issues with my workaround too, but after tweaking it seems to be more likely to work. It now explicitly returns false if not throwing the error again, and I've also updated it to account for errors that might not have a message, such as when dynamically skipping a test with this.skip(), etc.

// https://github.com/cypress-io/cypress/issues/761
Cypress.on('uncaught:exception', hackToNotFailOnCancelledXHR);
Cypress.on('fail', hackToNotFailOnCancelledXHR);

function hackToNotFailOnCancelledXHR(err) {
    const realError =
        Cypress._.get(err, 'message', '').indexOf(
            "Cannot set property 'aborted' of undefined"
        ) === -1;
    if (realError) throw err;
    else {
        /* eslint-disable no-console */
        console.warn(
            "Test threw a \"Cannot set property 'aborted' of undefined\" error, but we're continuing anyway. Details below."
        );
        console.warn(err);
        return false;
        /* eslint-enable no-console */
    }
}

[green-arrow]

@StormPooper - I got around to copying this update in but I still can't get anything after the first test to run. The first test runs correctly, but all subsequent tests never run and immediately show as passed.

[StormPooper]

@green-arrow we were seeing the same thing, but in our specific example, my updated hack function solved it. All I can suggest is maybe try playing with when it's called - try only calling it on uncaught:exception and not on fail and see if it makes a difference for you, I found we had to catch both originally, but maybe only one is required and that's causing your issue. Either way, it's a hack until Cypress is able to handle this scenario properly.

[green-arrow]

@StormPooper - thanks for that suggestion. Unfortunately, commenting out either doesn't work. Only using it on uncaught:exception results in the original cannot set 'aborted' failure, and only using it on fail results in all subsequent tests immediately passing and never running.

Hopefully Cypress is able to handle this scenario properly soon. It's pretty much the only thing standing in the way of migrating from TestCafe to Cypress.

[svegalopez]

I am also getting the error:

UnsubscriptionError: 1 errors occurred during unsubscription:
  1) TypeError: Cannot set property 'aborted' of undefined

This fixes it for me:

afterEach(() => {
    cy.wait(100);
})

I am on 3.1.1

[keepler-ivanmarques]

Is there any updates with this issue?

Thanks.

[jennifer-shehane]

Unfortunately in order to address an issue, we have to have a reproducible example provided. Can anyone provide the exact code + test code to reproduce this?

[amenk]

@jennifer-shehane We do not have a minimal reproducible example from our side. It was when cypress.io-testing a customer's Magento shop. We can try to reproduce with a standard Magento installation, also we could host it on some test server (but actually we were testing on localhost, so this has different timings).
Would that help in any way?

[amenk]

@jennifer-shehane We are able to reproduce against a website. We do not want to publicly share the website URL --- if you are interested, we can send the website URL via mail and post the tests here
a dot menk at imi dot de is mail mail

[bahmutov]

great, @amenk this would be helpful, I will email you

[amenk]

@bahmutov Sent you the info

[mlc-mlapis]

@bahmutov @jennifer-shehane ... I created a simple public reproduction demo:

Tested page: https://mlc-demo-cypress.firebaseapp.com
(Stackblitz source: https://stackblitz.com/edit/mlc-angular-demo-cypress)
Testing code:

describe('simple reproduction of a problem with cancelling XHRs', () => {

    before(() => {
        cy.visit('https://mlc-demo-cypress.firebaseapp.com');
        cy.wait(2000);
    });

    it('getting the album button and clicking it', () => {
        cy.get('[data-cy=getAlbums]').should('have.length', 1).click();
    });

    it('getting the todos button and clicking it', () => {
        cy.get('[data-cy=getTodos]').should('have.length', 1).click();
    });

    it('getting the user button and clicking it', () => {
        cy.get('[data-cy=getUsers]').should('have.length', 1).click();
    });
});

The result of the test looks:

And the error like:

[jennifer-shehane]

Hey @mlc-mlapis, thank you for a reproducible example!

[amenk]

@jennifer-shehane How is the status of this, now having a reproducible example?

[mlc-mlapis]

@brian-mann ... thank you, Brian.

[jennifer-shehane]

The code for this is done, but this has yet to be released. We'll update this issue and reference the changelog when it's released.

[brian-mann]

Released in 3.1.4.

[tomaass]

Hi, I'm using rxjs and redux-obsevables in my app. There was no problem in Cypress 3.1.2 with aborting requests by takeUntil operator from rxjs. But after upgrade to 3.1.4 I sometimes have an error like:

Error: Failed to read the 'responseText' property from 'XMLHttpRequest': The value is only accessible if the object's 'responseType' is '' or 'text' (was 'json').

I think it's caused by solving this 🐛

[mlc-mlapis]

@tomaass ... as always ... without a simple reproduction demo, it's hard to guess.

[tomaass]

@mlc-mlapis example of aborting request by using rxjs and redux-observables ;-)

const exampleEpic = action$ =>
  action$.ofType(FETCH_ACTION)
    .switchMap(() =>
      Observable.ajax.getJSON('example.url')
        .takeUntil(action$.ofType(ANOTHER_ACTION))
        .map(fetchExampleFulfilled)

1. If ANOTHER_ACTION comes before a response from a server it aborts the request and an error was thrown.

2. If another FETCH_ACTION comes before a response from a server it does the same after aborting

[mlc-mlapis]

@tomaass ... which RxJS version is used here? Because I can't see pipe-able operators.

[jennifer-shehane]

Hey @tomaass, this is a bug introduced in 3.1.4 - documented here: https://github.com/cypress-io/cypress/issues/3008

[nabby27]

Hey, I can solve it with cy.wait(100) before cy.visit()

[jennifer-shehane]

This issue will be closed to further comment as the exact issue here was resolved and tested.

If you're experiencing a bug similar to this in Cypress, please open a new issue with a fully reproducible example that we can run. There may be a specific edge case with the issue that we need more detail to fix.