Ability to pause response on runtime in the worker

[rahulsinghk]

Mock service Worker is an awesome library, it's very helpful to mock the API response.
however, while testing the component, you want to test the state where there is a delay in response from the server and you would manage some state between this.

See that the MSW has the delay() to add the delay in response. but here while testing we would like to have complete control over the delay in run time.

For example:- if I want to test the state where there is a delay in response. then I have to set the dealy() just right enough to test the use case and to avoid adding too much delay so that it takes too much time than required, making the test slow.

it would be noce to have the runtime modifier to pause the response and resume as we want.
For example:-
const { worker, rest } = window.msw
rest.pause() // this will pause the response
// do some asserts and test the state
rest.resume() // this will resume the reponse
// do some more asserts and test rest of the flow

[kettanaito]

Hey, @rahulsinghk. Thanks for your kind words and for proposing this feature!

if I want to test the state where there is a delay in response. then I have to set the dealy() just right enough to test the use case and to avoid adding too much delay so that it takes too much time than required, making the test slow.

rest.get('/user', (req, res, ctx) => {
  const url = new URL(location.href)
  const delay = url.searchParams.get('delay') || 0
  return res(ctx.delay(delay), ctx.text('hello world'))
})

This is a great pattern I've seen people use: you read the delay from your page's query parameters. This way you control response delays on runtime by appending the ?delay=X parameter to the page you're loading. Note that this reads the delay from the page but applies the delay to a particular response (GET /user in this example).

Most test runners execute assertions immediately so even a 100ms delay is enough to test the loading state, for example. Do you have a concrete test case in mind you could share where this doesn't apply?

Overall, having a pause/resume control over the network may be beneficial but I don't think it's what you need for testing in your particular case. If anybody needs this during development, you can utilize debugger in your request handler to pause your application:

rest.get('/user', (req, res, ctx) => {
  // The entire application will pause in the browser,
  // allowing you to inspect its state.
  debugger
})

[rahulsinghk]

hi
@kettanaito thanks for the response.
the suggestion you provide will work for my case.
as of now, I don't have a specific use case. :-)

[kettanaito]

I'm glad I was able to help. Don't hesitate to reach out if you have any more suggestions or struggles with what you want to achieve with MSW.

[rahulsinghk]

ya, recently I noticed one possible bug.
i filed it here #1112

[ArturDuziak]

Hey,
I will take the opportunity to share a scenario that we are having in a project where pause/resume would help out. I will start by saying that MSW is awesome, and we love it when paired with Playwright tests.
When it comes to the scenario it is very similar to the above example. We are mocking the request with a higher delay to check how the app behaves when we start doing something, then come back and wait the delayed response, something like this:

rest.get(..., delay: 3000);

// 1. Testing loading state
// 2. Testing changing the view and doing some actions
// 3. Coming back to the initial view and waiting for new state after delayed request is finished

Now the issue with the delay is that we are delaying tests and make them longer then these need to be, because in most of cases, 3 seconds delay is more than enough and it could be quicker - maybe 1 second or even less would be enough, but on slower machines or during some hiccups (happens on the CI) the tests could fail if the delay is lower than 3 seconds because the actions take longer, so we have to keep it just in case as we are not 100% sure how long the in-between actions take, this is making the test longer than these need to be to reduce the flakiness. If there were an option to pause and resume requests then it would solve the issue, the tests would resume the request when needed (for example in 95% of cases it would only take 500ms of delay but in other 5% it would have to be higher), it would make it more reactive and make tests as fast as possible.

This isn't a critical feature as the delay works fine, but for me having a pause/resume option would be fantastic for me as I would know the tests run as fast as possible and are reactive to changes. Let me know if you need some more explanation.

[kettanaito]

Hi, everyone! For those wondering how to pause/unpause a response with MSW, let me summarize and give a few suggestions below.

Basics

There's no concept of "pause" in HTTP responses because they are sent in one bulk. The exception being streams where you, indeed, can introduce an arbitrary pause between different streamed chunks. But let's talk about regular responses which is likely what you're mocking with MSW.

Using delay

The most straightforward way to "pause" a response is to pend a response via the ctx.delay() function.

rest.get('/resource', (req, res, ctx) => {
  // Delay this response by 3000ms.
  return res(ctx.delay(3000), ctx.text('Hello world!'))
})

Combine this with runtime handlers (the .use() API) and you can get a per-test delays to suit your needs.

Controlled delays

Using ctx.delay() works by accounting for a fixed interval. Sometimes that's not what you want (cc @ArturDuziak). In those cases, you can gain a granular control over the state of the response by using a promise.

In the example below, I will use DeferredPromise to delegate resolver resolution to the outer context (your actual test). This is how you do it:

import { DeferredPromise } from '@open-draft/deferred-promise'

it('my test', () => {
  const responsePromise = new DeferredPromise()

  server.use(
    rest.get('/resource', async (req, res, ctx) => {
      await responsePromise
      return res(ctx.text('Hello world!'))
    })
  )

  // ...do some actions.

  // This will resolve the promise, "unpausing" the response resolver
  // that awaits it above. The mocked response will be sent immediately.
  responsePromise.resolve()

  // ...do some assertions.
})

If you want more control over the response resolver execution in tests, I highly recommend this deferred promise pattern.

[ArturDuziak]

Thanks a lot for the quick reply - I didn't know about the possibility of using DeferredPromise, it looks great and should fit our purpose.