cypress: cy.request(...) fails if server is not available, with no option to return or catch the connection error

I was thinking we could add a new option to cy.request:

cy.request({
	url: 'http://something.invalid',
    failOnNetworkError: false // default: true
})
.then(res => {
	// res is an object with the Node.js Error `code` and `message` attached
    // should probably either have `res.error = true` or `res.error = { code, message }`
    // so users can tell it apart from a success
})

@Robdel12 If you want to open a PR to add this feature, that would be great! I believe you just need to update commands/request.coffee to accept the new option and then add a condition in the .catch for cy.request here:

https://github.com/cypress-io/cypress/blob/beaa105b50a2a5a1b989688396b25c58b2013772/packages/driver/src/cy/commands/request.coffee#L244-L253

Any new tests belong in in request_spec.coffee

Absolutely terrible. Cypress disallows using your own REST client or everything breaks. Meanwhile they don’t allow to catch errors? Currently at work in a situation where a cy.request breaks and there is no way to find out how. Please fix this.

Just expressing my interest in this feature.

My use case is that I want to add some logging whenever certain cy.request calls fail. I’m wishing for perhaps something like this:

cy.request("/seed/user", "POST", user).catch(e => {
  cy.log("Failed to call /endpoint. Are you sure the backend is running?");
  throw e;
})

(I have also tried to putting the cy.request inside a try {...} block, but that didn’t seem to work)

Some followup on what decision were made on Percy’s side - basically to move away from using the cy.request(). https://github.com/percy/percy-cypress/pull/140

But, we want to make some option available to cy.request() to make this easier. From internal discussions, some options like ‘failOnNetworkErrors: false’, ‘returnError: true’ @flotwig

Just want to bring this up again, do we have a proper way to handle the cy.request() error like @aommm example? Using a .catch seems like a good idea.

+1

FWIW, we plan on going forward with something like adding a .catch to cy.request. It would be great to collaborate on that 😊 We don’t have any issues doing the work and opening a PR but don’t want to step on toes or drop a surprise PR.

Thanks for the update Zach! I was hopeful 😊

I’m going to debug what’s going on in the screenshot above but a user is reporting that causes their test suite to fail when Percy isn’t running (even though we’re passing failOnNonZeroExit: false) with the v3.3.0.

So far I haven’t been able to reproduce but I’ll open an issue if I can. 👍

Curious to know as well 😃 We’re seeing some users report more errors with 3.3 and the workaround we have to do the healthcheck:

If I was doing this for my own test suite, I could use a new cy.task(...) to implement this healthcheck, but in the context of a Cypress plugin, that would require users to do additional setup in their plugins/index.js, in addition to what they already have to do in support/commands.js.

An alternate solution to this problem would be exposing an API in Cypress that allows me to programmatically add a cy.task(...) that I can then use in my custom command.

We’re in the early stages of looking into a way to make this easier for plugin authors and users. Probably some way to auto-load plugins. For now, as you said, you would have to instruct your users to load your plugin in 2 places.

We’ll also consider something like failOnStatusCode: false for cy.request to support this use-case.

I think your solution with cy.exec might be the best option for the time being.