-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
fix: worker being killed after being spawned and other worker bugs #13107
Conversation
PR is mostly done and I solved a few other bugs that I found while I was at it. I'm nos just trying to resolve the Windows weirdness that doesn't occur on my Windows machine. |
FINALLY!!! |
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.
yay!
const silent = this._options.silent ?? true; | ||
|
||
if (!silent) { | ||
console.warn('Unable to detect out of memory event if silent === false'); |
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.
we should only log this if _childIdleMemoryUsageLimit
is passed I think? Then we can probably also make it an error instead of warning
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.
same comment applies to thread worker - shouldn't we only monitor for OOM if the option is passed, otherwise keep old behavior?
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.
we should only log this if
_childIdleMemoryUsageLimit
is passed I think? Then we can probably also make it an error instead of warning
Yes to the first bit, i'm inclined to say no to the second. It can be useful for debugging to see the child output when a memory limit is in place, for example to see the exact thrown error message.
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.
same comment applies to thread worker - shouldn't we only monitor for OOM if the option is passed, otherwise keep old behavior?
Actually, ignore my previous comment....
Detecting an out of memory event and the worker crashing is independent of monitoring of the idle memory usage and rebooting as necessary. The _childIdleMemoryUsageLimit
applies to the latter case, the former is building and improving on #13054
Do I need better docs to explain that?
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've added some comments to explain
const handler = (chunk: any) => { | ||
if (this._state !== WorkerStates.OUT_OF_MEMORY) { | ||
let str: string | undefined = undefined; | ||
this._detectOutOfMemoryCrash(); |
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.
here as well, only if _childIdleMemoryUsageLimit
is passed?
|
||
export default abstract class WorkerAbstract | ||
extends EventEmitter | ||
implements Pick<WorkerInterface, 'waitForWorkerReady' | 'state'> |
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.
Create a new interface within types.ts
instead of Pick
ing here?
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.
It's an extremely limited use case just to prevent the class throwing typing errors, it didn't really seem necessary to create a new class just for that as it would have no utility elsewhere. Someone could create a different worker type in future and create a different abstract with totally different base props.
packages/jest-worker/src/workers/__tests__/WorkerEdgeCases.test.js
Outdated
Show resolved
Hide resolved
packages/jest-worker/src/workers/__tests__/WorkerEdgeCases.test.js
Outdated
Show resolved
Hide resolved
These test failures don't appear to be related to my changes, are they known to be flaky? |
@@ -44,12 +48,14 @@ export default abstract class WorkerAbstract | |||
|
|||
if (typeof options.on === 'object') { | |||
for (const [event, handlers] of Object.entries(options.on)) { | |||
if (Array.isArray(handlers)) { | |||
// Can't do Array.isArray on a ReadonlyArray<T>. | |||
// https://github.com/microsoft/TypeScript/issues/17002 |
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.
oh my 😅
Yeah, at times 😞 I restarted the failing builds now |
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.
looks great!
packages/jest-worker/src/workers/__tests__/WorkerEdgeCases.test.js
Outdated
Show resolved
Hide resolved
packages/jest-worker/src/workers/__tests__/WorkerEdgeCases.test.js
Outdated
Show resolved
Hide resolved
Hopefully this is the PR done |
@SimenB we're getting closer, tests are running locally in our main project on the alpha release and heap usage is remaining stable. What has me confused is I'm getting a tonne of snapshot failures, not sure if there's beena. chance to how snapshots are encoded between 27 - 29 which is causing it. Investigating now
Look at that heap usage :D |
Ah, it appears to be this change. This is looking good but I'd prefer more external validation |
Yep. https://jestjs.io/docs/next/upgrading-to-jest29#snapshot-format |
@SimenB I know you were hoping for a stable release last week had I not broken jest, I assume that means a stable release this week instead? |
Yep, that's the plan! Mostly waiting for a resolution on #12856 |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
#13106 (comment)
This adds a test case for the issue described above and can be demonstrated with.