Prevent console errors during tests

[LauSam09]

When testing API error cases, an error must be thrown from the query function in order to trigger the error state. This may be because of a server error or some other scenario that is expected to occur from time to time and warrants testing.

However this results in console errors. Previously we could override this behaviour by giving a custom logging function for console errors, but this has been deprecated and no alternative provided.

In #622, it was said that errors won't be logged to the console any more except where the developer should do something about them, but that doesn't seem to be the case to me.

See a minimal reproduction using @tanstack/[email protected]: https://codesandbox.io/p/sandbox/awesome-torvalds-pj2dvj

And an example of the unwanted output:

[louis-young]

Hi 👋

You don't need to throw an error. You could also reject the promise.

The setLogger function has been removed but you can still provide custom logging functions when instantiating the query client. Please see https://tanstack.com/query/v4/docs/react/guides/migrating-to-react-query-4#setlogger-is-removed.

In version 4, errors are no longer logged to the console in production. They are still logged in other environments. Please see https://tanstack.com/query/v4/docs/react/guides/migrating-to-react-query-4#logging-in-production

Providing a noop error logging function removes the error 🙂

[LauSam09]

Hi, thanks for responding so quickly.

Is there a reason to prefer rejecting the promise over throwing an error? The end result appears to be the same in that isError is true, and I find throw to be more intuitive.

We did just as you described and got warnings about logger being deprecated, but for some reason I can no longer reproduce that.

However, the docs state that the custom logger is deprecated and will be removed in the next major version, so I don't think this should be marked as answered just yet.

[louis-young]

No worries.

Is there a reason to prefer rejecting the promise over throwing an error?

No, I just wanted to point out that it's not the only way to make a query erroneous. Realistically, you'd be mocking at the network level via Mock Service Worker and running the same production code.

I don't think this should be marked as answered just yet.

You could also consider spying on the console error method. I'll leave this open until you receive the answer you're looking for 🙂

[LauSam09]

That was just a minimal repro. The actual code is making use of MSW, and we're currently spying on console error to get around this issue, but that doesn't seem ideal since what other errors are being obscured by having to do this?

I guess it seems like an assertion has been made that there is no need to customise logging behaviour outside of production, which is why the custom logger has been deprecated. That doesn't seem right to me, and I believe the option should be left in for cases such as this. Is this the appropriate forum to request that?

[louis-young]

The actual code is making use of MSW, and we're currently spying on console error to get around this issue, but that doesn't seem ideal since what other errors are being obscured by having to do this?

Awesome. You can deal with this by asserting on what the spy is called with and how many times it's called.

I guess it seems like an assertion has been made that there is no need to customise logging behaviour outside of production, which is why the custom logger has been deprecated.

Yeah, that's the decision that's been made from what I can discern from the upgrade guide.

That doesn't seem right to me, and I believe the option should be left in for cases such as this. Is this the appropriate forum to request that?

I think a new "Idea" discussion that's directed toward discussing the logging behaviour, the current API, and the new API/behaviour you'd like to propose would be ideal as I think your original question has been answered here. I say this as a more focused issue with less pollution is likely to gain more traction 🙂

[LauSam09]

Thanks, I like your suggestion around asserting on the spy and I'll recommend that to my team 🙂. I'll look at raising another discussion in the mean-time and mark this as answered.