-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(node-core): Ignore worker threads in OnUncaughtException #18689
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
size-limit report 📦
|
Lms24
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.
I have to admit, I was a bit confused about this change first, because I didn't know that childProcessIntegration also covers worker threads. To me, processes and threads are something different 😅 ... should we rename or split up the integration?
Anyway, the change itself looks reasonable to me. Thanks for fixing!
|
Looks like it originally only supported child processes and then I added support for worker threads here #15105. It would probably make sense to rename it! |
I created a ticket for it for further discussions: #18698 |
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
closes #18592
closes JS-1347
The onUncaughtException integration triggered for errors inside workers, which caused a wrong error code overall. Since we already have a Child Process integration which handles errors it would make most sense to disable the onUncaughtException integration entirely for workers.
Another option would also be to only ignore
shouldApplyFatalHandlingLogicfor workers, which was the main reason to exit the entire process, even though the error was handled - but I don't like this approach, since the child processes errors will be handled anyways in the other integration.Interesting finding: When using
--importor--requireCLI flags, these are propagated to worker threads, soSentry.init()runs twice: once in the main thread (isMainThread === true) and once in the worker (isMainThread === false). However, when using inlinerequire()inside a file, it is NOT propagated to workers, so it initializes only once withisMainThread === true. This means the bug primarily manifests with ESM (--import) or when CJS uses--require(which may be less common).The
caught-worker-inline.jstest always passes (inline require), whilecaught-worker.jswith--requireonly passes after the fix is applied, demonstrating this behavior.