Error message from shutting down a Jest + MSW test

[joshkel]

Bug report

Description / Observed Behavior

This bug arises from the interaction of MSW, Jest, and SWR, so I'm not positive that it's an issue in SWR. But (part of) it manifests as an SWR error, so I'll start by logging it here.

A unit test that uses MSW to mock responses for a component that uses SWR may log the following errors on shutdown.

TypeError: Cannot read properties of null (reading 'visibilityState')
    at Object.isVisible (/Users/josh/tmp/node_modules/swr/_internal/dist/index.js:136:59)
    at isActive (/Users/josh/tmp/node_modules/swr/core/dist/index.js:29:38)
    at /Users/josh/tmp/node_modules/swr/core/dist/index.js:284:29

Expected Behavior

No errors on shutdown.

Repro Steps / Code Example

https://github.com/joshkel/swr-msw-jest-bug

Clone, run npm i, then run npm test.

Additional Context

From what I can tell, here's the sequence of events:

• Jest tears down its jsdom environment when done.
• This causes MSW's fetch interceptor's use of location to throw an error, which SWR catches.
• SWR then goes into its error-handling logic to determine whether it should retry.

It seems to me that SWR should arguably skip any on-error-retry logic at this point, since it's been unmounted?

SWR version: 2.0.4

This problem started when upgrading from MSW 1.0.1 to 1.1.0. If I should raise an issue there instead, or in addition to, this project, please let me know.

[joshkel]

@koba04 , I see that you moved this into a discussion, but it seems to me that it's a bug within SWR? If all useSWR hooks have been unmounted, I don't believe it should be triggering onErrorRetry at all.

[huozhi]

We're reading visibilityState from document, is document missing to be defined in your testing runtime?

[joshkel]

It's provided; the problem is that the test runtime has started tearing down its jsdom environment, so accesses to document throw errors. I wouldn't have expected SWR to attempt to retry an operation after it's been unmounted, so I would not have expected this to be a problem.

For now, I'm working around this by restructuring my tests to ensure that no SWR requests are in flight (even if the tests don't actually depend on them) before finishing the test.

[giovannivocale-molar]

@joshkel how do you restructure your tests to ensure that no SWR requests are in flight? Can you show me an example? 🙏

[chrislicodes]

@joshkel can you please share a code snippet of your workaround?

[joshkel]

@giovannivocale-molar and @chrislicodes, I've typically been able to work around it by wrapping my code in SWRConfig with fallback and revalidateIfStale: false.

For example, if I have a test of MyComponent, which does a useSWR fetch of '/my/api/endpoint', I used to use MSW to mock replies of '/my/api/endpoint'. Instead, I now do something similar to the following:

const fallback = {
  '/my/api/endpoint': testData
};
render(
  <SWRConfig value={{fallback, revalidateIfStale: false}}>
    <MyComponent/>
  </SWRConfig>
)

Then the test doesn't have to do SWR fetches at all; it uses the static value from fallback and never re-fetches.

This works for tests that only need fixed / static values from SWR and when tests that don't depend on specific SWR results (e.g., the component under test uses SWR, but the SWR-dependent behavior isn't tested). I've not encountered this problem with more complex testing scenarios.

(Apologize for the delayed reply.)

[chrislicodes]

@joshkel thanks! For me the error disappeared after setting up "default" handler for each endpoint - however my tests are flaky now if I run them all together and if they rely on the same endpoint. I set the return value for each endpoint with server.use() in each test, so I have the feeling that server.use() is not registering the right return values? Or there maybe still is some cache flying around somewhere .. Anyhow, that is probably another issue

[tvthatsme]

Commenting here that I've raised a PR that addresses these issues that I've also been experiencing. Hopefully we can find a way to land these changes.

#2575

[chrislicodes]

Upvote, I have the same issue

[promer94]

You could provide your own isVisible implementation for testing environment.

/** @jest-environment jsdom */
import * as React from 'react'
import { Hello } from './test'
import { fireEvent, render, screen } from '@testing-library/react'
import { rest } from 'msw'
import { setupServer } from 'msw/node'
import { SWRConfig } from 'swr'

const renderWithSWRConfig = (component) => {
  const map = new Map()
  return render(
    <SWRConfig
      value={{
        provider: () => map,
        isOnline() {
          /* Customize the network state detector */
          return true
        },
        isVisible() {
          /* Customize the visibility state detector */
          return true
        },
        initFocus(callback) {},
        initReconnect(callback) {},
      }}
    >
      {component}
    </SWRConfig>
  )
}
const server = setupServer(
  rest.get('/example', (req, res, ctx) => {
    console.log('hello')
    return res(ctx.json('hello world'))
  })
)
server.listen()

afterAll(() => server.close())

test('hello world', async () => {
  renderWithSWRConfig(<Hello />)
  const textbox = screen.getByRole('textbox')
  fireEvent.change(textbox, { target: { value: 'query' } })
  fireEvent.change(textbox, { target: { value: '' } })
  fireEvent.blur(textbox)
})

[liamlows]

@promer94 Thank you so much for that snippet, I have been dealing with this for months and could not figure out how to mock that out!