Sentry-javascript: ノードの提案： `unhandledRejection`のログエラー

良さそうに聞こえますが、これがdebug: trueフラグの背後にあるべきかどうかはわかりません。
最後に、エラーストリームをSentryにリダイレクトするエラーハンドラーを意識的にアタッチします。

私もよくわかりません。

Sentryを有効にしても、キャッチされなかった例外のロギングを無効にする効果はありません。したがって、未処理のPromise拒否についても同じことが当てはまるはずです。 （ただし、この動作の違いは、SentryよりもNodeの方が一貫性がありません。）

Sentryを有効にすると、エラーが報告されていることは理解できますが、特に開発者では、コンソールログを別のものと考える傾向があります。 🤔

デフォルトのロギング動作は変更しません。キャッチされない例外の場合、ログ呼び出しをトリガーするのはノード自体です。

ここでの最善の解決策は、ドキュメントにそれについてメモして、残すことだと思います

process.on('unhandledRejection', (reason, p) => {
  console.log('Unhandled Rejection at:', p, 'reason:', reason);
});

誰かが警告を再度有効にしたい場合のスニペット。

ドキュメントで十分です。 少なくとも、セントリーは特別なことは何もしていません。 ここで問題になるのは本当にノードです。

完了https://github.com/getsentry/sentry-docs/pull/785

またはキャッチされなかった例外は、ログ呼び出しをトリガーしているのはノード自体です。

考え直してみると、それが本当かどうかはわかりません。

Sentryは、デフォルトのノード動作（ログ+終了）を無効にするuncaughtExceptionハンドラーを登録します。

ハンドラー（ defaultOnFatalError ）は、独自のログ呼び出しをトリガーします： https ：

キャッチされなかった例外のロギングを「復元」している場合、未処理のプロミスの拒否に対しても同じことを行う必要があると思います。

これを再開できますか？ 私の最後のコメントによると、Sentryは、キャッチされていない例外の場合と同様に、未処理のPromise拒否のログを復元する必要があると考えています。

この問題を見つけたのは、Sentryを使い始めたときに、 uncaughtExceptionがログにあり、 unhandledRejectionないため、コードを間違えたのではないかと思ったためです。 これらの2つのケースを同じように処理することは非常に理にかなっています。

したがって、両方をログに記録するか、どちらもログに記録しないと言います。

Nodeのコアからコードをコピーするよりも、これを処理するためのより良い方法を見つけました。

λ: node --unhandled-rejections=warn app.js

また、メインのドキュメントページhttps://github.com/getsentry/sentry-docs/pull/1099に含めることで明らかにしました

uncaughtExceptionとunhandledRejection処理が異なるのは、まだ奇妙だと思います。 SentryはuncaughtExceptionログを復元しますなぜunhandledRejectionでも同じことをしないのですか？ ユーザーは、そのノードフラグを使用することを覚えておく必要はありません。 🤔

unhandledRejectionに対して同じことをしないのはなぜですか

1つは重要であり（ unhandledExceptionはプロセスを強制終了します）、もう1つは情報提供であるため（したがって、エラーではなく警告です）。

順序を逆にしてデフォルトで警告を発行すると、 --unhandled-rejectionsがnoneに設定されているにもかかわらず、CLIの動作が中断されます。 現在、公式のノードドキュメントによれば、すべてが期待どおりに機能します。 この変更により、非標準になります。

NodeがunhandledRejectionもプロセスを強制終了することを決定したら（4つのバージョンでは現在：Pと言われています）、公式の仕様にも一致するように変更を加えます。

順序を逆にしてデフォルトで警告を発すると、CLIの動作が中断されます

@kamilogorekですが、 nodeで実行すると、 unhandledRejectionからconsoleログが記録されます。 したがって、公式のノードドキュメントに何が記載されているかはわかりませんが、少なくともそれが私が気付いた動作です。

@freeallは、 unhandledRejectionハンドラーをアタッチしない場合のみ。 以下のコードを実行すると、SDKがなくてもログに記録されないため、実行しているコードに注意する必要があります。

process.on('unhandledRejection', () => `¯\_(ツ)_/¯`);

そして、私たちはここでそれを行うことを非常に明確に述べています： https ：

システム統合は、デフォルトで有効になっている統合であり、標準ライブラリまたはインタープリター自体に結合されます。 それらは文書化されているので、それらが何をするのかを確認でき、問題が発生した場合は無効にできます。
OnUnhandledRejection
この統合により、グローバルな未処理の拒否ハンドラーがアタッチされます。

ノードの動作を変更したくないだけです。それだけです。 そして、動作は次のとおりです。「リスナーがいる場合は、出力しないでください。それでも警告が必要な場合は、フラグを使用してください。」 -そしてこれはまさに私たちがしていることです。

@kamilogorek私はあなたがどこから来ているのか理解しています。 しかし、Sentryのユーザーは、Sentryがプログラムの動作を変更しないことを期待していると思います。

SentryなしでunhandledRejectionを持っている場合、コンソールに表示されます。
SentryでunhandledRejectionを使用している場合、コンソールに表示されません。

私は個人的にセントリーが行動を変えるのが好きではありません。

しかし、それがNode.jsの設計方法です¯_（ツ）_ /¯
ハンドラーを追加すると、警告は消えます。 SDKの主な目的である未処理のエラーをキャッチする唯一の方法であるため、SDKはハンドラーを追加します。

もちろん、ノードの設計方法については正しいです。 ハンドラーをアタッチすると、警告は消えます。
人々が求めているのは、ノードのデフォルトの動作を模倣して、コンソールに記録することです。 変更された動作は、Sentryのようなツールに期待するものではありません

とにかく、あなたはこの振る舞いに取り掛かっているようですので、議論を続ける意味はありません。 しかし、答えるために時間を割いてくれてありがとう:)

@freeallもありがとう、両側を見るのはいつも良いです:)

明確にするために：Sentryを有効にすると、 unhandledException （exit + log）の動作は保持されますが、 unhandledRejection （log）の動作は保持されません。

|ハンドラー|ログ|終了|
|-|-|-|
| unhandledExceptionデフォルト|はい|はい|
| unhandledExceptionセントリー|はい|はい|
| unhandledRejectionデフォルト|はい|いいえ|
| unhandledRejectionセントリー|いいえ|いいえ|

現在、公式のノードドキュメントによれば、すべてが期待どおりに機能します。

ここでの「予想どおり」は、SentryがunhandledRejectionリスナーを登録していることをユーザーが理解していることを前提としています。 これは、ユーザーが心配する必要のない実装の詳細です。

私はあなたの主張を理解しています。 Sentryは--unhandled-rejectionsも尊重する必要があります。これは、フラグがnoneに設定されていて、Sentryがログを記録し続けている場合は実行されません。

@freeallコメントはこれをかなりうまくまとめています：

Sentryのユーザーは、Sentryがプログラムの動作を変更しないことを期待していると思います。

キャッチされていない約束の拒否は、「セカンドクラスのエラー」ではありません。 通常のエラーと同じように、アプリが破損する可能性があります。

何人かのユーザー（私を含む）がこの問題に遭遇したようで、将来さらに多くのユーザーがこの問題に遭遇するでしょう。

要約すると、Sentryはコンソールからのエラーを消音します。 そして、これがどのように混乱しているのかは明らかであり、おそらくほとんどの歩哨ユーザーによって意図されていないと思います。 彼らは、コンソールからエラーのサブセットを消音するために歩哨をインストールしません。

したがって、推論（ @kamilogorekによる）

それがNode.jsの設計方法です

私には少し不可解です。 これは歩哨の振る舞いをどのように決定しますか？

ユーザーが次のことを知っていることを期待する必要があります。

a）歩哨の内部動作（イベントハンドラーを登録します）

b）ノードの内部動作（ハンドラーを追加すると警告が消えます）

そして、そうでない場合は、そうすべきですか？

もちろん、「ユーザーはコードが内部で何をするのかを知っておく必要があります」と言っているのは正しいですが、現実は異なって見えます。 そして、ここでは歩哨の使いやすさを向上させるかどうかを決める機会があります。

「この特定の問題は気にしない」と言っても大丈夫ですが、「バグではなく、機能です」というような方法で描くのは不誠実に思えます。

TLDR：IMOH使いやすさを向上させ、初心者ユーザーの問題を減らしたい場合は、これを修正する必要があります。

@ OliverJAsh 、@ freeall
この問題に対してどのような解決策を使用しましたか？

@schumanndロード方法のスニペットを追加しました。 そして、「バグではなく、機能だ」という答えは満足のいくものではないように思われることに同意します。 セントリーがバグを食べてしまうので、多くのプログラマーがプログラムのバグを見つけられないのではないかと心配しています。 私にとって、Sentryのようなツールの最優先事項は、バグを作成することではなく、バグをキャッチすることです。

...
if (isUsingSentry) {
  // Log to console because Sentry overwrites standard behavior. https://github.com/getsentry/sentry-javascript/issues/1909.
  // Note that it doesn't overwrite for uncaughtException.
  process.on('unhandledRejection', console.error)
}
...

私はreactnativeで歩哨を使用しているので、この問題を修正するために

@ OliverJAsh 、@ kamilogorek
これを再開して修正してもらえますか？

Sentryは、コンソールでのエラーのログ記録方法を完全に混乱させるべきではありません。コンソールのログ記録はブラウザーでも抑制されるため、これはNodeの問題だけではありません。

デバッグしようとすると非常に煩わしく、JavaScriptのドキュメントでこれについて言及していなかったため、ステージングビルドのテスト中にコンソールを調べたときにエラーが発生していないと実際に思ったため、気づきませんでした。本番環境にデプロイされるまで、エラーが発生しました。 これは、エラー報告サービスにとって本当にくだらないユーザーエクスペリエンスであり、満足のいく顧客が必要な場合は修正する必要があります。

そして前に述べたように、約束の拒否は二流のエラーではありません-それらは他の未処理のエラーと同じように致命的である可能性があり、いかなる方法でも抑制されるべきではありません。

したがって、少しデバッグすると、コンソールログが抑制される理由が明らかになります。

Sentryは関数をwindow.onunhandledrejectionに割り当てます。ここに示すように、その関数はfalse返すため、コンソールのログが明示的に抑制されます。 そうですね、Sentryはデフォルトの動作を変更します-それはクールではありません。

幸い、既存の関数への参照を格納し、存在する場合はそれを呼び出します。
したがって、コンソールロギングを再度有効にするためのハッキーな回避策は、Sentryを初期化する前に次の行を追加することです。

window.onunhandledrejection = () => true;

さて、これを修正してください。そうすれば、そのような無意味なハッキングなしでデフォルトの動作を実現できます🙂

@schumannd問題を再開してください

@ thomas-darlingブラウザの変更に同意します。promiseに対してもtrueが返されるはずであり、変更できます。

ただし、ノードについては、1つの理由でまだ確信が持てません。 コードを現在のノード実装に結び付けます。 フラグに依存する代わりに内部をコピーし、v14で拒否動作が変更されることを約束する場合は、現在のノードのバージョンを検出し、それに応じて動作する必要があります。
内部ノードはリスナー配列をチェックし、リスナーがまったくない場合にのみ警告を発するため、リスナーから何を返すかは重要ではありません。この検出は変更できません-https：//github.com/nodejs /node/blob/7cf6f9e964aa00772965391c23acda6d71972a9a/lib/internal/process/promises.js#L163 -L216

ブラウザの変更に関しては良さそうです：+1：

ノードに関しては、Sentryでのログインを修正しないと、基本的にすべてのユーザーに自分でログインを強制するだけです。一部のユーザーは間違ってログインし、一部のユーザーはそれが必要であることに気付かない可能性があります。私がしたように、プロダクションバグに噛まれます。 それは良い開発者体験ではありません...

@ thomas-darlingどうやってそれを修正したいですか？ ノードのコード内にあるのと同じコードを再現しますか？

ドキュメントの最上部には、デフォルトのコンソールログを取得するために何をすべきかについての非常に目に見えるメモがあります-https ：//docs.sentry.io/platforms/node/

私はあなたのポイントを理解しています-ノードの動作を複製する必要があることは潜在的なメンテナンスの問題であり、ノードの場合、これは単純なコマンドラインフラグで解決できるのに役立ちます。

ただし、ノードの動作を複製したくない場合は、少なくともそのフラグが指定されていないときにコンソールに警告をログに記録します。これにより、ユーザーはエラーが抑制されていることと、それを回避する方法を認識できます。

これは、ノードの次のバージョンでさらに重要になります。このバージョンでは、未処理の拒否がデフォルトでプロセスをクラッシュさせます。これは、私が理解しているように、Sentryがハンドラーを追加したときに発生しません。
ノードでの新しいデフォルトの動作に依存しているユーザーは、後でSentryをインストールし、致命的なエラーが発生したにもかかわらずプロセスが突然続行されると、厄介な驚きを招く可能性があります。
これは、データの損失やその他の災害につながる可能性のある種類のことです。

私が見ているように、いくつかのオプションがあります：

1. Node.jsのやり方を複製する
2. 未処理の拒否がある場合は、 console.errorに書き込むだけです。
3. 開発者に表示されないようにエラーを抑制します

オプション1または2はどちらも問題ないと思います。 顧客はエラーを確認して修正できます。
絶対にすべきではないのはオプション3です。この場合、顧客にはエラーが表示されず、Sentryによってエラーが本番環境に移行します（ただし、エラー報告ツールの皮肉です）。 これは現在の動作であり、これは本当に停止するはずです！ セントリーは、エラーを悪化させるのではなく、エラーを見つけるのに役立つはずです。

オプション2を選択した場合でも、少なくとも開発者は拒否を確認し、別の動作（クラッシュなど）が必要であることに気付き、それを実装できます。 しかし、拒絶があったことさえ知らなければ、彼らはそれについて多くをすることができません。

これでうまくいくはずです。 https://github.com/getsentry/sentry-javascript/pull/2312
以下のコードを書くとまったく同じ効果があるため、独自のコールバックを追加する方法は追加しませんでした。

`` `js
Sentry.init（{
統合：[
new Sentry.Integrations.OnUnhandledRejection（{
モード： 'なし'
}）
]
}）;

process.on（ 'unhandledRejection'、（reason）=> {
//コールバック
}）

私にとってはTypeError: undefined is not a constructorます。 @sentry/react-nativeパッケージを使用しているためかもしれません。 ところで、そのパッケージにも同じ問題がありますか？

@schumannd @sentry/react-nativeは@sentry/nodeを使用しないため、この統合はありません。 そのためには、歩哨/ブラウザをリリースしたらバージョンを更新する必要があり、それは問題なく機能します（ハンドラーからtrueを返すように変更するのはデフォルトであり、構成できません）。

@kamilogorekは私には似合います👍

これをしてくれてありがとう！ これがリリースされたら、ここでpingを実行できますか？

@OliverJAsh ping :)

正しく理解していることを確認するために、Nodeの--unhandled-rejections=strictフラグを使用すると、Nodeは未処理の拒否を例外として発生させ、Sentryはその例外をインターセプトして報告しますか？ それが私が見ていると思うものです。

--unhandled-rejections=strict有効にしようとしたとき、 OnUnhandledRejections統合は効果がなかったようで、イベントリスナーが呼び出されなかったためです。

これに関するドキュメントを追加できれば素晴らしいと思います。

ドキュメントPRはすでに進行中ですhttps://github.com/getsentry/sentry-docs/pull/1351/

@OliverJAshこの変更は、 OnUnhandledRejection統合に、cliフラグのように動作させることができる新しいオプションが追加されたことです。

Sentry.init({
  integrations: [
    new Sentry.Integrations.OnUnhandledRejection({
      mode: 'none'
    })
  ]
});

は（概念的に） --unhandled-rejection=noneと同じであり、 warnとstrictについても同じことが
warn （現在はデフォルト）を使用すると、警告とエラー自体がログに記録されますが、プロセスは存続します。
strictを使用すると、ログに記録され、イベントがキャプチャされ、フラッシュされ（配信されるまで待機）、終了コード1でプロセスが強制終了されます。

それは理にかなっている。 統合によってノードフラグの動作が変更されないことを理解しています。 ただし、ノードフラグに関してSentryが（この統合以外で）どのように動作するかを正しく理解していることを確認できますか？

正しく理解していることを確認するだけです。Nodeの--unhandled-rejections = strictフラグを使用すると、Nodeは未処理の拒否を例外として発生させ、Sentryはその例外をインターセプトして報告しますか？ それが私が見ていると思うものです。

@schumannd参考までに、今朝、 @sentry/react-native 1.10.0 [編集：whoops、should be 1.1.0 ]をリリースしました。これは、最新バージョンの@sentry/browserを使用するように依存関係を更新します（リターンを含む） - true代わりに-上記のfalse修正）。

@lobsterkatie @ 1.3.7のようです。 。

したがって、1.10.0をインストールしようとしても機能しません。 どうすれば修正できますか？

@schumannd @lobsterkatieは1.1.0意味しました。これは、 @sentry/browser 5.9.0に更新したときです。 ロギングのレベルを設定するハンドラーオプションは、最近のバージョンの@sentry/react-nativeでも問題なく機能するはずです。