I just re-ran the tests and the logs looked right the next time. I have no idea how it got into that state or what I did to fix it other than a retry

I'm finding lots of issues interacting with table elements after using the inbuilt search function of the component. It always works locally but then within CI environment (GitHub Actions) it's very flaky and more often than not fails. Now there is no xhr call being made as it's filtering within the table data already, but I'm guessing it reloads the DOM elements or something funky is happening that impacts my test. The error that I get is described here, https://docs.cypress.io/guides/references/error-messages#cy-failed-because-the-element-cannot-be-interacted-with - however after reading this and the associated blog posts I'm struggling to figure out what assertion I need to make to have the Cypress internal retries work and eventually find the element. Is there something I'm missing here? I won't necessarily know the amount of rows in the table based off the search so I can't assert off that as in the example here: https://www.cypress.io/blog/2020/07/22/do-not-get-too-detached/

HI , I am getting an error in Cypress while executing it inside the CI/CD Pipeline.

I have created a customized package of cypress on the NPM Registry. While executing inside the CI/CD Pipeline and installing the package , I am executing a command which runs my tests cases inside the tags of feature files

All the test cases are passing but I am getting this warning due to which my Pipeline is failing

(node:1963) Warning: a promise was created in a handler at internal/timers.js:461:21 but was not returned from it, see http://goo.gl/rRqMUw at Function.Promise.cast (/home/vsts/.cache/Cypress/7.7.0/Cypress/resources/app/packages/server/node_modules/bluebird/js/release/promise.js:225:13) (Use

Cypress --trace-warnings ...

to show where the warning was created) ##[error]Bash wrote one or more lines to the standard error stream. ##[error](node:1963) Warning: a promise was created in a handler at internal/timers.js:461:21 but was not returned from it, see http://goo.gl/rRqMUw at Function.Promise.cast (/home/vsts/.cache/Cypress/7.7.0/Cypress/resources/app/packages/server/node_modules/bluebird/js/release/promise.js:225:13) (Use

Cypress --trace-warnings ...

to show where the warning was created

can some one help me with the solution , that seems to be an issue with cypress

I have tried all the solutions but getting the same error

can you make an example site showing the table that fails to test on CI?

have you tried upgrading from Cy v7 to v9?

I've tried but it's difficult to reproduce. In our CI-CD we start a database and application container, as well as a node frontend and the cypress runner. So I'm guessing it's a resources strain that's causing the issue and the same reason why I can't reproduce locally. Essentially it's a bootstrap vue table where I click on a record which displays a button. The button looks visible in the failing test screenshot (I even use the should be visible chainer) but the click event fails.

does it work reliably if you add

cy.wait(10000)

before clicking on the button? If it works with a wait, then it means there is some javascript that is late to the party and attaches the event listener much later than the button is displayed

##[error]Bash wrote one or more lines to the standard error stream.

where is this coming from? It looks like you have some warning being printed to stderr, but this wouldn't cause Cypress to fail your tests, it seems like some additional tooling in your CI pipelining is failing when it gets stderr.

I will test that out now with a few iterations and see how I go. If that's the case is there a 'Cypress' way to fix it? I see a long GitHub issue thread about similar issues from a lot of Cypress users. I also understand that it's probably not an easy problem to tackle globally as there could be a number of factors but it seems like this affects a lot of 3rd party modules/frameworks where the engineer doesn't necessarily have control over how the component renders or when it re-renders etc.

@User , I have tried this , but same error is coming on cypress 9 as well.

@User , I am only getting this error while I am running cypress tests from a package , not while running cypress tests as a task

if possible can we set up a call ?

as this issue of cypress is not letting my pipelines to run inside the CI/CD pipeline

are you talking about any devOps tooling which we have added ?

So trying to use the 'testfiles" and "ignoreTestFiles" option - but it appears I have something wrong. Any help would be appreciated. { "projectId": "76chwx", "baseUrl": "https://ui.qa.someplace.com", "testFiles": [ "api/eComm/*.js", "api/giftCard/*.js", "api/lodging/*.js", "api/oauth/*.js", "api/restaurant/*.js", "api/retail/*.js", "api/settlement/*.js", "UI/*.js" ], "ignoreTestFiles": [ "api/lodging/authEMV.js", "api/restaurant/authEMV.js", "api/restaurant/saleDevice.js", "api/retail/authDevice.js", "api/retail/saleEMV.js" ], "env": { "UI_Url": "https://ui.qa.someplace.com", "api_url": "https://api.qa.someplace.com", "uat_url": "https://api.uat.someplace.com", "login_url": "/login", "products_url": "/products", "video": "false" } }

I think you want "api/eComm/*.js" etc.

See / read this https://cypresstips.substack.com/p/wait-for-3rd-party-javascript

sure we can set up a call, but my rate for private consultation starts at $500 and goes up from there ...

I do - but there are some I did not that I thought I could exclude

@User by the way one of my colleagues wanted to test how the tests behaves on slower computers/networks (they need more time for some things). So during the test in the gui he throttled the network. That lead to a funny effect. Cause chrome just holds it back from ui while the intercept still thinks it can resolve the wait("@myrequest") while the data still not been there. Not sure if i should call it a bug or and edge case

would be interesting to hear your opinion

My opinion: https://glebbahmutov.com/blog/3rd-party/ works pretty well to slow down specific requests

he wanted to emulate a slow response to identify which cypress tests run too slow on less powerfull notebooks and fail because the computer doesnt handle cypress + app fast enough. its a bit of a special thing maybe

Sure, that is a good test. In addition to slowing down the network using cy.intercept, you can also wrap the returned JavaScript with

setTimeout(() => ..., 1000)

to simulate the network call returning, but the browser not evaluating it until some time later. Sky is the limit