Skip to content
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.

Sign up for GitHub

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: silently capture unhandled rejections, don't force-exit #4291

Merged
merged 1 commit into from
Feb 28, 2022
Merged

fix: silently capture unhandled rejections, don't force-exit #4291

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions docs/getting-started/migrating-to-v9.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,11 +32,13 @@ While there is no hard style guide governing this, we tend to use readonly prope

The `serialport` library was upgraded to version 10.x. It is now built using N-API, which should avoid having to recompile it after upgrades. Due to slight API changes, overwriting the dependency to specific `9.x` versions is no longer possible.

## Error-reporting is now opt-in
## Error-reporting is now opt-in and less disruptive

It was found that the global `unhandledRejection` event handler which Sentry registers, has an influence how the application will behave in case of an unhandled rejection. This can affect applications on Node.js before `v15`, which are going to crash instead of logging a warning. While we do believe no rejection should be silently unhandled, we don't want to break existing applications.
It was found that the global `unhandledRejection` event handler, which Sentry registers, has an influence how the application will behave in case of an unhandled rejection.
The default behavior of Node.js is to log a warning before `v15` and to crash on `v15` or later, unless the `--unhandled-rejections` flag is changed. With the Sentry event handler, the application would always crash, regardless of any other `unhandledRejection` event handlers.
The Sentry event handler has been changed so that it no longer force-exits the process in case of an unhandled rejection. This is now the application's responsibility.

Therefore, error reporting is now opt-in using `driver.enableErrorReporting()`. We kindly ask you to do so in production environments, so unhandled errors in the library can be discovered more quickly.
In addition, error reporting is now opt-in using `driver.enableErrorReporting()`. We kindly ask you to do so in production environments, so unhandled errors in the library can be discovered more quickly.

## Migrated the `<homeid>.json` network cache file to `<homeid>.jsonl`

Expand Down
2 changes: 1 addition & 1 deletion packages/zwave-js/src/lib/telemetry/sentry.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -242,7 +242,7 @@ export async function initSentry(
integrations: [
new Sentry.Integrations.OnUncaughtException(),
new Sentry.Integrations.OnUnhandledRejection({
mode: "strict",
mode: "none", // Let applications take care of force-exiting
}),
new Sentry.Integrations.FunctionToString(),
new Integrations.Dedupe() as any,
Expand Down