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
Changes from 1 commit
71d0080
8c6ab73
86acdf1
718425b
de0c0e8
d83aa84
9435d0b
29e1193
c23f581
e8a8058
4e0b399
790f772
b4151ea
2753069
617e102
28230da
60b5b1b
a9a3779
cdf9627
7a79c92
11fd6f8
55f4097
723951b
a062850
66c83bd
c47404d
9331bd2
5058e14
ddbfb5e
811e228
197c0da
0d0d03e
11e8b25
8f427a4
57d3b20
d3abe14
f704620
5a840bb
d6b2db0
202323b
9e7d081
75037d2
37c5a43
3e8b3ae
fab410a
8e4a31e
b974eea
1e1023d
ab2931d
c610bdb
ee20013
bd786b1
613fcf2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,7 +17,11 @@ 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 commentThe reason will be displayed to describe this comment to others. Learn more. Create a new interface within There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
{ | ||
private __state = WorkerStates.STARTING; | ||
/** | ||
* DO NOT WRITE TO THIS DIRECTLY. | ||
* Use this.state getter/setters so events are emitted correctly. | ||
*/ | ||
#state = WorkerStates.STARTING; | ||
|
||
protected _fakeStream: PassThrough | null = null; | ||
|
||
|
@@ -28,12 +32,12 @@ export default abstract class WorkerAbstract | |
protected _resolveWorkerReady: (() => void) | undefined; | ||
|
||
public get state(): WorkerStates { | ||
return this.__state; | ||
return this.#state; | ||
} | ||
protected set state(value: WorkerStates) { | ||
if (this.__state !== value) { | ||
const oldState = this.__state; | ||
this.__state = value; | ||
if (this.#state !== value) { | ||
const oldState = this.#state; | ||
this.#state = value; | ||
|
||
this.emit(WorkerEvents.STATE_CHANGE, value, oldState); | ||
} | ||
|
@@ -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 commentThe reason will be displayed to describe this comment to others. Learn more. oh my 😅 |
||
if (typeof handlers === 'function') { | ||
super.on(event, handlers); | ||
} else { | ||
for (const handler of handlers) { | ||
super.on(event, handler); | ||
} | ||
} else { | ||
super.on(event, handlers); | ||
} | ||
} | ||
} | ||
|
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 warningThere 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.
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.
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 #13054Do 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