Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting tough to debug error: #2823

Closed
tnrich opened this issue Nov 22, 2018 · 18 comments
Closed

Getting tough to debug error: #2823

tnrich opened this issue Nov 22, 2018 · 18 comments

Comments

@tnrich
Copy link
Contributor

tnrich commented Nov 22, 2018

Here's a screenshot of the error I'm getting with cypress.

image

There's not much info in the stack trace and searching for _jp.av0adc2("o"); isn't helpful. Can someone offer some pointers for how to get a more understandable error? Thank you!

Thanks!

@jennifer-shehane
Copy link
Member

Can you provide your test code? Feel free to remove any sensitive information.

@jennifer-shehane jennifer-shehane added the stage: needs information Not enough info to reproduce the issue label Nov 26, 2018
@tnrich
Copy link
Contributor Author

tnrich commented Nov 26, 2018

@jennifer-shehane I would love to be able to give you an easier test case to reproduce this, unfortunately it seems like you'll have to clone my project. Here is the code that is failing:

// import dragMock from 'drag-mock'

describe("tabs", function() {
  beforeEach(() => {
    cy.visit("http://localhost:3344/#/Editor"); //switching this to http://teselagen.github.io/openVectorEditor/#/Editor works even though the code should be the same (except one is running in production mode)
  });
  it("can drag tabs", function() {
    dragBetween(".veTabLinearMap", ".veTabProperties");
    cy.get(`[data-test="ve-draggable-tabs1"] .veTabLinearMap`);
    dragBetween(".veTabPlasmid", ".veTabProperties");
    cy.get("[data-test=ve-draggable-tabs0] .veTabLinearMap");
    cy.get("[data-test=ve-draggable-tabs1]").should('not.exist')
  });
});

function getCenter(el) {
  const b = el.getBoundingClientRect();
  const x = (b.right - b.left) / 2 + b.left;
  const y = (b.bottom - b.top) / 2 + b.top;
  return [x, y];
}
function dragBetween(dragSelector, dropSelector) {
  cy.clock();
  cy.get(dragSelector).then(el => {
    let dragSelectDomEl = el.get(0);
    cy.get(dropSelector).then(el2 => {
      let dropSelectDomEl = el2.get(0);
      const [x, y] = getCenter(dragSelectDomEl);
      const [xCenterDrop, yCenterDrop] = getCenter(dropSelectDomEl);
      cy.get(dragSelector)
        .trigger("mousedown", {
          button: 0,
          clientX: x,
          clientY: y
        })
        .tick(1000);
      // drag events test for button: 0 and also use the clientX and clientY values - the clientX and clientY values will be specific to your system
      cy.get(dragSelector)
        .trigger("mousemove", {
          button: 0,
          clientX: x + 10,
          clientY: y + 10
        }) // We perform a small move event of > 5 pixels this means we don't get dismissed by the sloppy click detection
        .tick(1000); // react-beautiful-dnd has a minimum 150ms timeout before starting a drag operation, so wait at least this long.

      cy.get("html") // now we perform drags on the whole screen, not just the draggable
        .trigger("mousemove", {
          button: 0,
          clientX: xCenterDrop,
          clientY: yCenterDrop
        })
        .tick(1000);
      cy.get("html")
        .trigger("mouseup", { // Causes the drop to be run
          button: 0,
          clientX: xCenterDrop,
          clientY: yCenterDrop
        })
        // .wait(200)
        // Can now test the application's post DROP state
    });
  });
}

unfortunately I can't reproduce this when running at http://teselagen.github.io/openVectorEditor/#/Editor only when running at http://localhost:3344/#/Editor

Here are steps to get my project running locally:

git clone https://github.com/TeselaGen/openVectorEditor
cd openVectorEditor/
yarn      (must have node 8+ )
yarn start
yarn run c    (runs the cypress tests locally)
click "tabs" test

You should see an error like the following:
image

@tnrich
Copy link
Contributor Author

tnrich commented Nov 26, 2018

Another strange little tidbit.. this test also seems to run just fine when running headlessly via the cypress run command:
image

@tnrich
Copy link
Contributor Author

tnrich commented Nov 30, 2018

@jennifer-shehane I think the label on this can now be changed from needs info?

@tnrich
Copy link
Contributor Author

tnrich commented Nov 30, 2018

Oh, it appears that it is originating from sockjs-node
image

Here is an issue I've started over there as well to try to better understand where this error is coming from sockjs/sockjs-node#246

@jennifer-shehane jennifer-shehane added stage: needs investigating Someone from Cypress needs to look at this and removed stage: needs information Not enough info to reproduce the issue labels Dec 3, 2018
@tnrich
Copy link
Contributor Author

tnrich commented Jan 18, 2019

Hmm I'm getting it again:

TypeError: _jp.ailf1zb is not a function

But only sometimes.

@jennifer-shehane could you give me more info on where those socks-js calls would be coming from in cypress?

image

Oh... maybe they're not coming from cypress but instead from my webpack hot reloader?

@bahmutov
Copy link
Contributor

bahmutov commented Jan 18, 2019 via email

@tnrich
Copy link
Contributor Author

tnrich commented Jan 18, 2019

Okay, I'm filtering those out now by doing:

beforeEach(function() {
  cy.server({
    whitelist: xhr => {
      if (xhr.url.indexOf('sockjs-node/') > -1) return true
      //return the default cypress whitelist filer
      return xhr.method === 'GET' && /\.(jsx?|html|css)(\?.*)?$/.test(xhr.url)
    }
  })
})

@bahmutov does that mean we won't hit that error anymore, or that we just won't see the sockjs requests?

@bahmutov
Copy link
Contributor

bahmutov commented Jan 18, 2019 via email

@tnrich
Copy link
Contributor Author

tnrich commented Jan 18, 2019

Yeah, it looked like that was the case. I wonder what is going wrong in these sometimes failing cases..

@Chris2011
Copy link

Chris2011 commented Mar 21, 2019

I have a similar problem that the tests hangs, when I have this in my test: cy.task('log', cy.get('input[e2e-id="password-field"]'));. On the console, I only see the describe string. When I call the tests with --headed I see this:

image

It hangs on the XHR request. This is my test code:

it('password field should hide password in general.', () => {
        cy.visit('/');
        cy.get('input[e2e-id="password-field"]').should('exist');
        cy.get('input[e2e-id="password-field"]').should('be.visible');
        cy.task('log', cy.get('input[e2e-id="password-field"]'));
        cy.get('input[e2e-id="password-field"]').should(
            'have.type',
            'password',
        );
    });

and this is the code inside my index.js file in the plugins folder:

// HINT: Needed for Cypress to print into the node console.
    on('task', {
        log(message) {
            console.log(message);
            return null;
        },
    });

The code from @tnrich only hides it, but I don't know how to fix the root cause.

@jennifer-shehane
Copy link
Member

@Chris2011 There is not an assertion chain have.type. You can see all supported assertion chains here: https://on.cypress.io/assertions

I think you want

cy.get('input[e2e-id="password-field"]').should(
            'have.attr',
            'type',
            'password'
        );

Did you open the devtools to see if there is an error logged in there?

@jennifer-shehane
Copy link
Member

@tnrich Was your issue resolved? Can this be closed?

@tnrich
Copy link
Contributor Author

tnrich commented Mar 29, 2019 via email

@Chris2011
Copy link

@jennifer-shehane thx, I handled it by myself with the have.type from this url: https://docs.cypress.io/guides/references/best-practices.html and searched for have. and found the attr thing. In general, I don't use the GUI, I'm running the Headless electron. I only wanted to check whats happening, that my tests hangs and tried the GUI and saw the xhr request.

@jennifer-shehane jennifer-shehane removed the stage: needs investigating Someone from Cypress needs to look at this label Mar 29, 2019
@paulfalgout
Copy link
Contributor

I ran into this issue all of the sudden.. Tests passed yesterday. Today rerunning CI on the same branch and they fail consistently with the webpack-dev-server error. While I don't know why it's happening I have a solution for anyone stumbling upon this. The solution above to swallow the xhr requests doesn't work if the error happens outside of the test run (like in beforeEach or afterEach) but there should really be a reason to be running hmr for tests which is what is causing the issue. The easiest way to fix this if you can is to use --inline false with the server https://webpack.js.org/configuration/dev-server/#devserverinline

paulfalgout added a commit to RoundingWell/care-ops-frontend that referenced this issue Aug 9, 2019
@jbinto
Copy link

jbinto commented Aug 12, 2019

We saw this on one of our apps in a CI run this morning. Never seen it before and re-running it made it go away. If we see it recur, I'll update this thread with how we fixed it.

@jennifer-shehane
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants