worker: emit worker exit notifications on BroadcastChannel - #65575
SudhansuBandha wants to merge 4 commits into
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #65575 +/- ##
==========================================
+ Coverage 90.05% 90.07% +0.02%
==========================================
Files 751 751
Lines 254868 254944 +76
Branches 48107 48122 +15
==========================================
+ Hits 229531 229653 +122
+ Misses 16511 16471 -40
+ Partials 8826 8820 -6
🚀 New features to boost your workflow:
|
4dd297f to
d8a79bf
Compare
| * Type: {Function} Invoked with a received message cannot be | ||
| deserialized. | ||
|
|
||
| ### `broadcastChannel.onworkerexited` |
There was a problem hiding this comment.
This needs a YAML tag for version history tracking
There was a problem hiding this comment.
Updated the fix in latest commit
|
|
||
| if (worker_exit_notifications_.empty()) return false; | ||
|
|
||
| *notification = worker_exit_notifications_.front(); |
There was a problem hiding this comment.
Prefer std::optional<> instead of assigning to out parameters (esp. if they have non-trivial types)
There was a problem hiding this comment.
Updated the fix in latest commit
| return; | ||
| } | ||
| continue; | ||
| } |
There was a problem hiding this comment.
This is duplicating a significant amount of logic – is there a reason that this needs to be a new message type, and cannot be something that would be conveyed through normal messages in the queue?
There was a problem hiding this comment.
I tried to implement a separate pipeline since this notification is related to worker lifecycle instead of inter thread messages of Broadcast Channel. If this is not something to be done then I will update the PR to use existing pipeline for emitting these lifecycle events.
There was a problem hiding this comment.
I think that would significantly simplify the implementation and make it easier to write consumers -- events will happen in order from their perspective, rather than seeing a worker exit before all its messages have been sent
There was a problem hiding this comment.
Sure, I will implement the suggested changes. Thanks for your feedback!!
There was a problem hiding this comment.
Updated the implementation to use existing queue for these events
| const ExitCode exit_code = environment->exit_code(ExitCode::kNoFailure); | ||
|
|
||
| Debug(this, | ||
| "Worker exiting: thread_id=%" PRIu64 ", exit_code=%d", |
There was a problem hiding this comment.
| "Worker exiting: thread_id=%" PRIu64 ", exit_code=%d", | |
| "Worker exiting: thread_id=%d, exit_code=%d", |
Debug() doesn't care about the actual type anyway
There was a problem hiding this comment.
Updated the fix in latest commit
f23efdb to
b1c9fb9
Compare
|
The GitHub Actions CI workflow had previously failed due to problems with GitHub. I triggered re-runs, however there are now other failures. The PR branch is now more that 300 commits behind the Please rebase the branch in this PR according to the Pull requests documentation to make sure that all available fixes are included. |
b1c9fb9 to
f3007df
Compare
|
GitHub Actions CI workflow tests are hanging up and will probably time out after the default 6 hour maximum duration is reached. It does not look like other current PRs have this issue. See Pull requests > Step 6: Test
with further details under BUILDING > Running tests. |
|
@MikeMcC399 I have not received any failure on my Windows machine because of my changes in PR. Can you provide me a suitable approach where I can recreate the CI failure on Windows machine. Will WSL/MSYS2 help in this regards? |
|
That does sounds suspicious! I have retriggered all the tests once again. If you still get failures, then I suggest once again that you rebase (see instructions in #65575 (comment)). Since you are no longer a "First-time Contributor" the workflows should trigger automatically, after you force push, without them needing to be triggered manually by a team member. |
|
The tests are timing out again, so I don't think that rebasing will solve the issue judging by your comment that you are testing on Windows. Although Node.js supports both Windows and Unix (Linux & macOS), Windows is in practice secondary for development. If you test only on Windows, then you will not see problems that only affect Unix. I can't advise you in detail how to set up a Unix environment on your Windows machine. There are various options available, including dual-booting with Ubuntu, running Ubuntu in WSL2 under Windows, running Ubuntu in VMware Workstation or using a Docker image. |
|
Thank you @MikeMcC399 for your help. I believe I have missed a failing test in my changes which I am currently looking at it. Hopefully CI issues will get resolved after this. |
f3007df to
c1b0497
Compare
Expose worker termination notifications through BroadcastChannel so consumers can observe when a worker exits andinspect its thread ID and exit code. Fixes: nodejs#59053 Signed-off-by: SudhansuBandha <bandhasudhansu@gmail.com>
c1b0497 to
ccc39ae
Compare
|
@MikeMcC399 I have fixed the failing test but still the CI issue is not getting resolved. If it is possible, can you or anyone else debug these failing CI issues against the test suite on Linux/MacOs. I am not able to reproduce on Windows and due to limited hardware resources it is difficult for me to have a dual setup of Windows and Linux on my machine |
|
I'm sorry, I won't be able to help you further with the test problems. |
Expose worker termination notifications through BroadcastChannel so consumers can observe when a worker exits and inspect its thread ID and exit code.
Fixes: #59053