-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
fix(bail): fix race condition in bail #8971
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
I don't know why the tests are failing. @sheremet-va any idea? |
They are flaky. If you didn't touch them, don't worry. As a note, your test needs to be inside |
|
Thanks for the review! 🙏 I've moved the test to |
|
@sheremet-va I've improved the test, made it silent, assert happy path and clarified with some comments. What do you think? |
| // Wait for any ongoing cancellation to complete before accepting new tasks | ||
| if (this.cancellingPromise) { | ||
| await this.cancellingPromise |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this change will start some previous run's tests too. I have no idea why this._isCancelling was required before - @sheremet-va I think that's something you added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea why
this._isCancellingwas required before
The comment explains it:
Prevent new tasks from being queued during cancellation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These kinds of checks exist to catch any unintended behaviours
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that we just await here and then let it continue, doesn't it mean it's going to continue the run it was intended the cancel? Should it return instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that was the previous cancellation (because of bail). So it needs to wait for that to finish.
| // Set flag to prevent new tasks from being queued | ||
| this._isCancelling = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pool should already have had all tests queued at this point. Or if there was another group, the ctx.isCancelling in node/pool.ts should have prevented them from being queued.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this was true, there wouldn't have been an issue #8852
AriPerkkio
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me this looks more like race condition in core.ts:
We start cancelling here:
vitest/packages/vitest/src/node/core.ts
Line 861 in 26d2b60
| this.isCancelling = true |
And it's then overwritten by
vitest/packages/vitest/src/node/core.ts
Lines 707 to 710 in 26d2b60
| // previous run | |
| await this.runningPromise | |
| this._onCancelListeners = [] | |
| this.isCancelling = false |
This is noticable with your reproduction. No idea why that happens.
|
@AriPerkkio I now use your implementation with I've implemented the changes requested by @sheremet-va @AriPerkkio I'm not familiar enough with the code base to know how cancellation in |
| test('cancels previous run before starting new one', async () => { | ||
| const results: Record<string, unknown>[] = [] | ||
|
|
||
| const { ctx: vitest, buildTestTree } = await runVitest({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this bug reproduce with runVitest? I'm only able to see it via createVitest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get reproduce it structurally, as long as I use pool: 'threads'
|
The underlying bug is rather in |
Description
Resolves #8852
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
pnpm-lock.yamlunless you introduce a new test example.Tests
pnpm test:ci.Documentation
pnpm run docscommand.(no new functionality)
Changesets
feat:,fix:,perf:,docs:, orchore:.