[Bug?]: Scenario teardown on test timeout

[cjreimer]

What's not working?

@dac09 Thanks so much for fixing the scenario issue described in #10068!!!

I'm now trying V7.1.0 and seeing a related bug, where teardown is not happening on a test timeout, and then subsequent tests fail when trying to create the scenario. Depending upon what's happening on the PC, we intermittently get timeout errors, so this is not a consistent issue for us, but definitely confuses things when a timeout error does occur.

Here's an example terminal log...

testing users service › returns all users

    thrown: "Exceeded timeout of 5000 ms for a test.
    Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."

      43 | //-----------------------------------------------------------
      44 | describe('testing users service', () => {
    > 45 |   scenario('returns all users', async (scenario: StandardScenario) => {
         |   ^
      46 |     mockCurrentUser(castCurrentUser(scenario.user.userAdminOrgA))
      47 |
      48 |     const result = await users()

      at node_modules/@redwoodjs/testing/config/jest/api/jest.setup.js:103:12
      at scenario (api/src/services/users/users.test.ts:45:3)
      at Object.describe (api/src/services/users/users.test.ts:44:1)

  ● user function › queries a specific user in the database

    PrismaClientKnownRequestError:
    Invalid `getProjectDb()[model].create()` invocation in
    D:\CENGYS\Dev\cengys-r\node_modules\@redwoodjs\testing\config\jest\api\jest.setup.js:196:64

      193 scenarios[model] = {}
      194 for (const [name, createArgs] of Object.entries(namedFixtures)) {
      195   if (typeof createArgs === 'function') {
    → 196     scenarios[model][name] = await getProjectDb()[model].create(
    Unique constraint failed on the fields: (`code`)

      at _n.handleRequestError (node_modules/@prisma/client/runtime/library.js:123:6854)
      at _n.handleAndLogRequestError (node_modules/@prisma/client/runtime/library.js:123:6188)
      at _n.request (node_modules/@prisma/client/runtime/library.js:123:5896)
      at l (node_modules/@prisma/client/runtime/library.js:128:10871)
      at seedScenario (node_modules/@redwoodjs/testing/config/jest/api/jest.setup.js:196:36)
      at Object.<anonymous> (node_modules/@redwoodjs/testing/config/jest/api/jest.setup.js:106:28)

This one might be trickier to solve. I'm wondering whether Redwood should keep track of whether the scenario is seeded or not. Perhaps the code could do a double-check check at the beginning of a scenario call if it is still seeded, and if so, do a teardown before seeding the scenario. Or do you know of a way to catch when a jest timeout event occurs?

How do we reproduce the bug?

No response

What's your environment? (If it applies)

No response

Are you interested in working on this?

• I'm interested in working on this

[Tobbe]

@cjreimer Just a heads-up that Danny is traveling. So might not see this until next week

[cjreimer]

Thanks for the update @Tobbe. This isn't a high priority for us, as timeouts only happen intermittently.