essentially I just want it to return what docs.find returns

btw docs is an array that is separate from doc

ID of raw html element

Hi, does anyone else get this weird error ? I get it whenever I try to execute cy.intercept()

my cypress version is 6.14.15

cy.intercept(
    {
        method: 'POST', // Route all POST requests
        url: 'https://api.database.com/username_password', // that have a URL that matches '/users/*'
    },
    [] // and force the response to be: []
    ).as('User has been registered') // and assign an alias

    cy.wait(['@User has been registered'])

here's the code

Not sure about using [] to force the response. Just wondering if it's the cause. I couldn't find any example on the intercept commands guide with this format.

The [] response works fine, can you share a more detailed reproducible example @User ? Also, are you using a CLI to scaffold your project that could be overriding the Cypress version with an older version?

Hello, guys, I solved it. The problem was with local and global scopes of the isntalled versions of Cypress

apparently my project-local scope cypress was at version 3. The problem is that when I ran "npm cypress --version" it did not give me the right one. and cy.intercept was actualy introduced in version 6. I discovered it by completely re-installing cypress using npm and now it works.

Hey guys, I've got recurring problems with

should

command. Here is one case (I will simplify it a bit). There is a form that has two two div elements - first (

country field

) has input of autocomplete type. Second one's (

state field

) input is initially simple text input, but it's final type depends on `country field`'s content: a) if

country field

!= Germany, then

state field

is simple input b) if

country field

== Germany, then

state field

becomes a single select list Now, I want to check whether

state field

type is changing correctly. I spotted that initially

state field

has type attribute equal to

text

. Type attribute changes to

hidden

when it becomes a list. So I came up with following assertion:

cy.get(stateField).find('input').invoke('attr', 'type').should('eq', 'hidden');

but no mater what I do, it always results in error:

Hey Dante, two things -- are you able to confirm that the state field is actually updating in the application? You may want to throw a cy.pause() before the cy.get() and inspect the page while the test is paused to confirm the attribute type is actually hidden. Second question -- you are using a .then() after the custom cy.fillSingleAutocomplete(). Is there a reason for that?

I did what you suggested and it looks like confirmation, that state field is in deed updating.

and about this .

then()

- I was simply checking whether chaining is going to solve my problem. Thought that maybe Cypress is checking state field to quickly.

@User Cool! Thanks for checking, that rules out application issues. Cypress will automatically wait up to 4 seconds for the assertion to be true before failing. This timeout can be increased if needed on the command level. I'd remove the .then(). I noticed you're using .invoke(), but unless you're looking to execute a function on the previous element (such as change or remove an attribute), you should use its(), according to our docs. https://docs.cypress.io/api/commands/invoke https://docs.cypress.io/api/commands/its You may also want to ensure that you are getting the correct element. It's hard to tell from the snippet because it doesn't show how stateField is defined, but make sure you are getting the correct element by hovering over that command and seeing what it's grabbing in the DOM. And finally, you may need to increase the default timeout for the command if you think it's taking longer than 4 seconds for the attribute to update. https://docs.cypress.io/guides/core-concepts/retry-ability#Increase-time-to-retry 🤞

Anyone noticed issues when communicating with external API? I have an issue when I call external API using cy.request(). The counter just remains to clock, but Cypress actually just stop the execution and nothing happens. When running in pipeline, pipeline time even exceeds its maximum allowed time (120 mins in Bitbucket pipelines).

Cypress 8.7.0

Thanks for your suggestions @User! (Un)fortunately none of your ideas about

state field

worked, but it showed me error in my ways. The problem was, that user's input was still focused on

country field

, hence trigger for changing `state field`'s input type wasn't send. I solved it by "clicking" somewhere else in the DOM. But about this .invoke() vs .its()... I tried using .its() like you suggested, but Cypress for some reason can't find input's type at all. I'll attach some screenshot showing this. I tried solving this with increasing timeout for .its(), but it failed as well. Anyway I can work without solving this, but I have a feeling it can bite me in the future as well 🙈

Anyone having trouble testing login with "sso" in chrome 95? I have a login test, where the application uses the "SSO" method and was working normally before the chrome version upgrade.

Hey Dante, I'm glad you were able to figure it out! That's interesting that invoke is working but not its 🤔 I haven't seen that before. I'd recommend submitting a GitHub issue with a reproducible example with invoke() working but not its(). I'm not sure why that would be happening and the docs recommend its() when just trying to get a property to assert against. In the meantime, if invoke() is working for you I'd say keep using that to avoid the error, but I agree it's something that should be reviewed.

Hi Team, these network calls abort only when run on cypress. If i open this application manually it works. Anyone has faced a similar issue ? I'm on Cypress 7.7 version @User

Sorry for late response 🙈 Will I'll try submitting an issue on GitHub like you suggested. "Reproducible example" will be tricky, since I encountered this issue at work 😅 Thanks! ❤️

Haven't seen this specifically but a few things to try -- Are the network calls actually being aborted when you view in the Network tab in the browser? What is the specific response message? Does that give you any indication on what's happening? Are there security requirements (IP address, proxy, etc.) for the API endpoint that need to be addressed? If those ideas don't help, you can create a GitHub issue with a reproducible example so the team can investigate.

Understandable! A simplified version of the code that demonstrates the issue lets the team investigate. Sometimes users will create the public GitHub issue, and then share a private repo/example with us directly separately. Let me know if you'd like to go this route and I can help coordinate.

Thanks for these ideas. I'll check and raise a GIThub

I'm trying to run a test against the staging environment of a work project. It runs fine the first time around but then the second time around it seems to not respond well to a redirect, causing the side panel to close and the tests to cease running. When I run it in headless mode it works fine. It seems to be specific to the page I'm trying to test, but I'm not entirely sure what causes it. It's an open source project which should help with reproduction, in the screencast below I first clear the directory it opens when you go to File -> View App Data (as suggested in issue #2132), then I run the test which works fine, close the chrome window and try to run the test again where the issue occurs. If I don't clear the app directory it'll keep doing this.

any idea what's going on here?

running it headless works fine every time also

Hi there Does one of you know how to debug net-stubbing ? I'd like to be able to hook into the Cypress code responsible for stubbing here https://github.com/cypress-io/cypress/blob/ab401ecd359234985b269d8283ff526136eeb4d4/packages/net-stubbing/lib/server/middleware/request.ts#L30 while running a test. We face some really weird issue where an intercept works only once for the same pattern on our Nuxt application. Thanks

Went ahead and created an issue instead, I saw a couple of similar issues that were closed because they weren't as easily reproduced, so hopefully this one is a little bit more actionable 😅