Have delays changed between v0.36.8 and v1.3.5?

[cmacdonnacha]

Hi there 👋

We're in the process of upgrading from a very old version of MSW v0.36.8 to v1.3.5 (we're not quite ready to jump to v2 just yet). I know a lot has changed since v0.36.8 but one thing I noticed is that UI tests which check for loading indicators or disabled buttons while waiting for a response are now failing. I have found that the main reason for this is because the request is resolving so quickly that the test doesn't have a chance to check for the loading state, and therefore fails.

Apologies I don't have a full reproducible, but I'm hoping we don't necessarily need it as we I'm pretty much just wondering if you would know off the top of your head something that's changed internally in MSW or the interceptors packages between v0.36.8 to v1.3.5 that might ring a bell here. Perhaps MSW used to add delays internally before but doesn't anymore?

The test is something like this:

it('disables button while adding user', async () => {
  const user = userEvent.setup();
  const submitButton = await screen.findByText('Add user');
  
  expect(submitButton).not.toBeDisabled();
  
  // This action will send a POST to /addUser
  await user.click(submitButton);
  
  // The button should be disabled while we wait.
  // ❌ This fails as the test says "Received element is not disabled". Using "waitFor" also doesn't seem to work here.
  expect(submitButton).toBeDisabled();

  expect(await screen.findByText('User has been added')).toBeInTheDocument();
  expect(submitButton).not.toBeDisabled();

We are loading the handler in our setupTests file, not directly in the test:

// addUserHandler.ts

rest.post(`/addUser`, (req, res, ctx) => {
  return res(ctx.status(200), ctx.json({}));
})

Adding a delay in the handler does work, but I don't want this to slow down each test that uses this shared handler, just one particular test that checks for the disabled button.

rest.post(`/addUser`, (req, res, ctx) => {
  return res(ctx.status(200), ctx.json({}), ctx.delay(300));
})

It works absolutely fine with v0.36.8, but not after upgrading to v1.3.5. I appreciate we're on an old version, but as I said it would be great if there was something that might jump out. Here's a diff of the public/mockServiceWorker.js if that helps:

https://www.diffchecker.com/eG2mP74P/

Appreciate everything about MSW 🙏

[cmacdonnacha]

From looking at the diff, I'm guessing it's related to the setTimeout which was included in 0.36.8, creating at least one tick of delay which gave your the UI time to update and show the loading state.

// v0.36.8
case 'MOCK_SUCCESS': {
  return delayPromise(
    () => respondWithMock(clientMessage),
    clientMessage.payload.delay,
  )
}

function delayPromise(cb, duration) {
  return new Promise((resolve) => {
    setTimeout(() => resolve(cb()), duration)
  })
}

// v1.3.5
case 'MOCK_RESPONSE': {
  return respondWithMock(clientMessage.data)
}

async function respondWithMock(response) {
  await sleep(response.delay)
  return new Response(response.body, response)
}

[kettanaito]

Hi, @cmacdonnacha 👋 Great to see you updating.

First thing to point out, v0 and v1 are practically the same, in a sense that v1 doesn't include any breaking changes (the package got bumped to v1 accidentally and we rolled with it because the APIs have been stabled for years at that point).

MSW never had any implicit delays, you always have to define one yourself.

In your case, I recommend adding a delay to the matching request handler only in the disabled button state test case. Rely on the fallthrough so you don't have to repeat the resolver implementation:

test('...', async () => {
  server.use(
    rest.get('/resource', async (req, res, ctx) => {
      await ctx.delay('infinite')
    })
  )
})

Since that handler doesn't return any mocked responses, MSW will run it, wait for the delay, and normally continue with running the matching base handler. But here, I recommend using the infinite delay mode not to subject your tests to flakiness related to the exact delay duration.

[cmacdonnacha]

Thanks for the reply @kettanaito!

The main reason I asked this originally was because as I switch between branches I'm noticing that the test works absolutely fine when on v0.36.8, but then fails every time I switch to v1.3.5. I'm making sure to do a full clean npm ci each time as well. Hence why I was thinking the way delays or promises are handled. Just curious really.

I'll try out those suggestions though, thanks!