Change Request: Warn when an unintercepted request is detected

[TrevorBurnham]

What problem do you want to solve?

One of MSW's most useful debugging features is that (by default) it emits a console warning if it detects a request that doesn't match any defined routes. As far as I can tell, Mentoss doesn't have this feature, even as an option. You can assert that all defined routes matched a request, but you can't assert that all requests matched a defined route.

What do you think is the correct solution?

When there's a request that doesn't match a defined route, MSW emits a warning that looks like this:

  console.warn
    [MSW] Warning: captured a request without a matching request handler:

      • GET http://127.0.0.1:55984/api

    If you still wish to intercept this unhandled request, please create a request handler for it.
    Read more: https://mswjs.io/docs/getting-started/mocks

That's great, actionable output when figuring out why my tests aren't working. I look at that message and say "OK, I need to either mock the /api route, or prevent that request from being fired during this test."

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[nzakas]

This is already built in to Mentoss by default. When a request is made to an unmatched route, you get a verbose error message like this:

No route matched for POST https://api.example.com/user/settings.

Full Request:

POST https://api.example.com/user/settings
Authorization: Bearer XYZ
Content-Type: application/json

{"name":"value"}

Partial matches:

🚧 [Route: POST https://api.example.com/user/:id -> 200]:
  ✅ URL matches.
  ✅ Method matches: POST.
  ❌ URL parameters do not match. Expected id=123 but received id=settings.

🚧 [Route: POST https://api.example.com/user/settings -> 200]:
  ✅ URL matches.
  ✅ Method matches: POST.
  ❌ Headers do not match. Expected authorization=Bearer ABC but received authorization=Bearer XYZ.

[TrevorBurnham]

Ah, interesting! Somehow I'm not getting those messages in my tests. I'll try to put together a replication.

[nzakas]

Yeah, if you have a repro case, I'd be interested in investigating. This was actually the first feature I implemented and the desire for these verbose error messages is why I created Mentoss initially. 😄

[TrevorBurnham]

Here's a quick-and-dirty repro: https://codesandbox.io/p/devbox/6s5fgw

In the app where I encountered the issue, I was using TanStack Query to fire the fetch requests. And indeed, that would seem to be the critical factor:

If I put this code in the React component, I get the expected "No route matched" error:

useEffect(() => {
  setTimeout(() => fetch("/useEffect"), 10);
}, []);

But with this TanStack Query code, Mentoss doesn't emit any error:

useQuery({
  queryKey: ["todos"],
  queryFn: () => {
    console.log("queryFn was called");
    return fetch("/todos");
  },
});

That's despite the console confirming that queryFn was indeed called.

In the app where I encountered this issue, Mentoss is successfully intercepting requests generated from TanStack Query. So I'm puzzled:

• If a fetch fired from TanStack Query has a matching route in Mentoss, it's intercepted.
• But if a fetch fired from TanStack Query doesn't have a matching route in Mentoss, it doesn't trigger the "No route matched" error.

[nzakas]

To me, that sounds like useQuery() is wrapping the call to fetch() with some kind of error handler that is swallowing the error. I'll reopen this to take a look when I have some time.