You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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
The text was updated successfully, but these errors were encountered:
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...
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?
The text was updated successfully, but these errors were encountered: