Sentry-javascript: メインのAPIキャプチャ*メソッドからpromiseを返します

これを強調していただきありがとうございます。完全に同期していないことを明確にするために、「トランスポート」はバックグラウンドで実行されています。 したがって、厳密に言えば、イベントがセントリーにヒットすることは保証されません。

eventIdはSDKでローカルに生成され、サーバーでイベントを取り込むために使用されます。

これを明確にするために、ドキュメントを更新します。

わかりました。明確にするために、ここで概説されていることを実装する必要があります： https ：

これは正しいですか、@ HazAT？

@rhyek Corrent、すべてが送信されていることを確認したい場合は、フラッシュを待ってすべてが送信されていることを確認できます。

capture*メソッドからの約束を公開する方が良いのではないでしょうか。 APIは、イベントが送信されることを確認するためにawaitする必要があること、または送信されることを期待して忘れる必要があることをユーザーに通知するため、より明確になります。 closeとflushはどちらも、非同期であると考えられてきた同期を作成しようとするあいまいなユーティリティのメソッドです。 さらに、これらの方法は両方とも完全に壊れています。実際、かなりの数の癖があります（これはバグだと思いますが、おそらくこれはそれらを見ている人のPOVに依存します）：

• 目的timeoutに渡されたflushそれが要求の送信を中断することによって、トランスポートから尊敬されていないため、nullです。 タイマーの期限が切れると、返されたプロミスをfalseに解決するだけです。 私はまだそのようなコードと振る舞いの有用性を自問しています...
• flushメソッドは、呼び出されるたびに新しいpromiseを返します。これは、 timeoutに達するとすぐに解決されます。 2つの問題があります。少なくともブラウザのコンソールでのテストでは、 setIntervalによって実行されるコード全体が非常に遅いことと、タイムアウトの期限が切れてから数秒後にPromiseが解決されたことです。 2番目のより重要な問題は、 _isClientProcessing関数のコードが呼び出されるたびにタイムアウトをクリアすることです。したがって、誰かがPromise.all([fush(), flush()])ようなことをしている場合（なぜ彼がやるべきかわかりません）ただし、APIは、誘惑されるたびに新しいpromiseを返すため、そのようなpromiseは解決されません。

Corrent、すべてが送信されていることを確認したい場合は、フラッシュを待ってすべてが送信されていることを確認できます。

間違っています。上記の私のポイントを参照して、フラッシュを待っていてもすべてが送信されていることを確認できない理由を理解してください。 そのようなAPIの設計は完全に壊れており、すべてのユーザーに対して機能することさえできないシャットダウンAPIを構築しようとするのではなく、イベントの送信を表すpromiseを待つという選択をユーザーに任せない理由を本当に理解できません。 UnifiedAPIが機能する言語

イベントがついに決着したときに解決する約束にアクセスできると思います
このスレッドで説明されている他のメソッドに加えて送信されると、
たくさんの意味があります。

土、2019年5月11日には、12：29 PMステファノArlandini [email protected]
書きました：

キャプチャからの約束を公開する方が良いのではないでしょうか*
メソッド？ 約束を返すことでユーザーに次のことを知らせるので、APIはより明確になります
イベントが送信されることを確認するために、または単にそれを待つ必要があります
それが送られることを期待して火をつけて忘れてください。 クローズとフラッシュの両方が
同期したものを作成しようとするあいまいなユーティリティ
非同期であると考えてください。 さらに、これらの方法は両方とも完全に壊れています。
実際、かなりの癖があります（これはバグだと思いますが
おそらくこれはそれらを見ている人のPOVに依存します）：

• フラッシュに渡されるタイムアウトの目的はnullではないためnullです
  リクエストの送信を中断することにより、トランスポートによって尊重されます。 これ
  タイマーの期限が切れると、返されたpromiseをfalseに解決するだけです。
  私はまだそのようなコードと振る舞いの有用性を自問しています...
• flushメソッドは、呼び出されるたびに新しいpromiseを返します。
  タイムアウトに達するとすぐに解決されます。 2つの問題があります：
  setIntervalによって実行されるコード全体は、少なくとも
  ブラウザのコンソールでの私のテスト、そして約束は多くのことを解決しました
  タイムアウトの期限が切れてから数秒後。 2番目のより重要な問題は
  _isClientProcessing関数のコードがタイムアウトをクリアすること
  呼び出されるたびに、誰かがPromise.all（[fush（）、
  flush（）]）（なぜ彼がそれをすべきかはわかりませんが、APIが返すので
  彼がそれをしたくなるたびに新しい約束）そしてそのような約束は
  解決されることはありません。

Corrent、すべてが送信されていることを確認したい場合は、フラッシュを待つことができます
すべてが送信されていることを確認します。

間違っています。上記の私のポイントを参照して、待っているだけでもフラッシュする理由を理解してください
すべてが送信されていることを確認できません。 そのようなAPIデザインは
完全に壊れていて、なぜユーザーに任せないのか本当に理解できません
イベントの送信を表す約束を待つという選択
すべての人に機能することさえできないシャットダウンAPIを構築しようとする代わりに
UnifiedAPIが機能する言語

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/getsentry/sentry-javascript/issues/2049#issuecomment-491533914 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAFLTSVSICZ7Y26UHCSMKWLPU4GATANCNFSM4HKUJ5ZQ
。

また、結果を返すメソッドがバックグラウンドで何かを実行することは期待していません。これはユーザーの混乱の原因となるためです（もちろん、この問題の主な質問です）。 代わりに、約束が返される場合、それは将来来る何かの単なるプレースホルダーであり、まだ準備ができていないことは明らかです。 それを待つか、単にファイアアンドフォーゲットするかの選択は明らかにユーザーに任されています。 また、イベントIDはローカルで生成されるため（ところでそれを行う理由はわかりません）、何らかの理由でトランスポートがイベントを送信できず、それについてさえ知らない

@sentry/nodeにアップグレードして以来、Sentryでかなりの問題を抱えていましたが、より良い解決策がraven-nodeまで、おそらく

サーバーレス実行の最後に任意のタイムアウトでキューをドレインする必要があることは、解決策ではなく、ハックのように感じられます。 🤔

うまくいく可能性のあるもののより多くの例を探している人のために—私は＃1449内のいくつかの解決策がフラッシングなどに関して役立つことを発見しました、彼らはこの問題の多くについても議論します。

（ラムダとサーバーレスに焦点を当てていますが、フラッシングアプローチであるため、同じ概念が他の環境でも機能する可能性があります）。

毎回フラッシュする必要のない、より良い方法があることを強く望んでいます。

このスレッドで述べられていることに完全に同意します。IMOは、バックグラウンドで非同期性を隠す同期メソッドを使用することは非常に混乱します。
歩哨チームがこのようにする非常に正当な理由があるかもしれませんが、とにかくドキュメントの更新は本当にありがたいです。

@cibergarriこの理由は、歩哨APIへの潜在的に遅いネットワーク呼び出しでユーザーランドコードをブロックすることなく、eventIdをすぐに返すことができるようにするためだと思います。 非同期APIから値を返すのは混乱を招き、非同期トランスポート層の呼び出しに十分な時間滞在しないサーバーレス実行コンテキストでエラーがサイレントに失われる可能性があることに同意します。 1つの解決策は、関数を2つに分割して、ユーザーが非同期動作にオプトインする必要があるようにすることです。

Sentry.captureException() // -> returns eventId after successful submission to sentry
Sentry.captureExceptionAsync() // -> returns promise

またはパラメータとして、例えば

Sentry.captureException(ex, {async: false}) // ->  default, returns eventId after successful submission to sentry
Sentry.captureException(ex, {async: true}) // -> returns promise

イベントIDは常にクライアントで生成されるため、非同期または同期APIは重要ではなく、その結果、イベントが実際に送信されたかどうかを示す良い指標にはなりません（別の問題imo）。 また、ずっと前にPHP SDKに対して、 capture*メソッドごとに同期メソッドと非同期メソッドの両方を使用する同様のソリューションを提案しましたが、拒否されました。 Unified APIが非同期性を隠したい、開発者が約束を公開したくないという本当の理由を完全には理解していませんでしたが、これを変更することにそれほどオープンではなかったようです。

残念ながら、この問題により、サーバーレス環境でのトラッキングエラーがエラーを起こしやすくなるため、Sentryから切り替えました。 （ああ、皮肉なことです。）

capture*Asyncメソッドは非常に役に立ちました👍

これに関する最新情報を入手できますか？

@marcospgp正確に何を知りたいですか？ ダニエルが書いたすべては今でも真実です。

ドキュメントは別として、コメントやコメント自体に対する反応から、ユーザーが約束にアクセスしたいと思っていることはかなり明らかであり、この私見を許可しない理由はありません。

残念ながら、これはv6リリースの前には発生しません。これは、メインAPIに重大な変更が加えられ、多くの変更が必要になるためです。 これをメモしておくために、これをロードマップに追加します。