Sentry-javascript: 从主要 API capture* 方法返回一个承诺

感谢您强调这一点，以明确它不是完全同步的，“传输”在后台运行。 所以严格来说，不能保证该事件会命中 Sentry。

eventId在 SDK 本地生成，将用于摄取服务器上的事件。

我们将更新我们的文档以明确这一点。

好的，只是为了澄清一下，确实有必要实现这里概述的内容： https :

这是正确的吗，@HazAT？

@rhyek Corrent，如果您想确保发送所有内容，您可以等待刷新以确保发送所有内容。

从capture*方法中公开承诺不是更好吗？ API 会更清晰，因为返回一个 Promise 让用户知道他们必须await以确保事件被发送，或者只是一劳永逸地希望它被发送。 close和flush都是模棱两可的实用方法，它们试图使被认为是异步的东西同步。 另外，这两种方法都完全被破坏了：事实上，有很多怪癖（我会说这是一个错误，但这可能取决于查看它们的人的 POV）：

• 传递给flush的timeout的目的是空的，因为它不被传输通过中断请求的发送来尊重。 它只是在计时器到期时将返回的承诺解析为false 。 我仍然在问自己这种代码和行为的效用......
• flush方法每次被调用时都会返回一个新的 Promise，只要达到timeout就会解决。 有两个问题： setInterval执行的整个代码非常慢，至少在我在浏览器控制台中的测试中是这样，而且 promise 在超时过期后很多秒后才解决。 第二个也是更重要的问题是_isClientProcessing函数的代码每次调用都会清除超时，所以如果有人在做Promise.all([fush(), flush()])事情（我不知道他为什么要这样做它，但由于 API 每次他可能想要这样做时都会返回一个新的 Promise），那么这样的 Promise 将永远不会被解决。

Corrent，如果您想确保所有内容都已发送，您可以等待刷新以确保所有内容都已发送。

不正确，请参阅我上面的观点以了解为什么即使等待刷新也无法确定所有内容都已发送。 我会说这样的 API 设计完全被破坏了，我真的不明白为什么不让用户选择等待代表发送事件的承诺，而不是尝试构建一个甚至无法为所有人工作的关闭 API统一 API 应该工作的语言

我认为可以访问在事件最终结束时解决的承诺
除了此线程中描述的其他方法外，发出
很有意义。

2019 年 5 月 11 日星期六下午 12:29 Stefano Arlandini [email protected]
写道：

从捕获中公开承诺不是更好吗*
方法？ API 会更清晰，因为返回一个承诺让用户知道
他们必须等待它以确保事件已发送或只是
即发即弃，希望它被发送。 close 和 flush 都是
模棱两可的实用程序，它试图使已被同步的东西
认为是异步的。 另外，这两种方法都完全被破坏了：在
事实上，有很多怪癖（我会说这是一个错误，但
可能这取决于看他们的人的 POV）：

• 传递给flush的超时的目的是null，因为它不是
  通过中断请求的发送受到传输的尊重。 它
  只是在计时器到期时将返回的 Promise 解析为 false。
  我仍然在问自己这种代码和行为的效用......
• 每次调用flush方法时都会返回一个新的promise
  达到超时后立即解决。 有两个问题：
  setInterval 执行的整个代码非常慢，至少在
  我在浏览器控制台中的测试，promise 解决了很多
  超时到期后的秒数。 第二个也是更重要的问题是
  _isClientProcessing 函数的代码清除超时
  每次它被调用，所以如果有人在做类似 Promise.all([fush(),
  flush()]) （我不知道他为什么要这样做，但是由于 API 返回
  每次他可能想去做的时候，一个新的承诺）那么这样的承诺就会
  永远得不到解决。

Corrent，如果您想确保所有内容都已发送，您可以等待刷新
以确保所有内容都已发送。

不正确，请参阅我上面的观点以了解为什么还要等待冲洗您
无法确定所有内容都已发送。 我会说这样的 API 设计是
完全坏了，我真的不明白为什么不留给用户
选择等待代表发送事件的承诺
而不是尝试构建一个甚至无法为所有人工作的关闭 API
统一 API 应该工作的语言

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/getsentry/sentry-javascript/issues/2049#issuecomment-491533914 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAFLTSVSICZ7Y26UHCSMKWLPU4GATANCNFSM4HKUJ5ZQ
.

我还要说，我不希望返回结果的方法在后台运行某些东西，因为这会给用户造成混淆（当然也是这个问题的主要问题）。 相反，如果返回了一个承诺，那么很明显它只是一个占位符，用于表示将来会出现但还没有准备好的东西。 显然是等待它或只是触发并忘记它的选择由用户决定。 此外，由于事件 ID 是在本地生成的（顺便说一句，我没有看到任何这样做的理由），您可能会使用无效的东西（因为它会立即返回），因为由于某种原因传输无法发送事件而您没有甚至不知道

自从我们升级到@sentry/node以来，Sentry 遇到了很多麻烦，我们可能会回到raven-node直到有更好的解决方案。

在每次无服务器执行结束时必须在任意超时时排空队列，这肯定感觉更像是一种 hack，而不是解决方案。 🤔

对于那些寻找更多可能有用的例子的人——我发现#1449 中的一些解决方案对冲洗等很有帮助，他们也讨论了很多这个问题。

（他们专注于 lambda 和无服务器，但相同的概念也可能在其他环境中工作，因为它是刷新方法）。

绝对渴望在某些时候有一种更好的方法，而不是每次都冲洗。

完全同意这个线程上所说的，IMO 有一个在后台隐藏异步的同步方法真的很令人困惑。
也许哨兵队有一个很好的理由这样做，无论如何对文档的更新将不胜感激。

@cibergarri我认为这样做的原因是可以立即返回eventId，而不会阻塞对哨兵api的潜在慢速网络调用上的用户态代码。 我同意从异步 api 返回值会令人困惑，并可能导致无服务器执行上下文中的错误静默丢失，这些错误对于异步传输层调用的停留时间不够长。 一种解决方案是将函数分成两部分，以便用户需要选择异步行为，例如

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*方法设置同步和异步方法，但被拒绝了。 我不完全理解统一 API 想要隐藏异步性和开发人员不想公开承诺的真正原因，但在我看来，他们并没有那么愿意改变这一点。

可悲的是，这个问题让我放弃了 Sentry，因为它使无服务器环境中的跟踪错误太容易出错。 （哦，讽刺。）

capture*Async方法会非常有帮助👍

我们能得到这方面的更新吗？

@marcospgp你想知道什么？ 但以理所写的一切直到今天仍然是真实的。

我认为除了文档之外，从评论和评论本身的反应中可以清楚地看出，用户希望能够访问这些承诺，并且没有充分的理由不允许这个恕我直言

不幸的是，它不会在 v6 发布之前发生，因为它正在对我们的主要 API 进行重大更改，并且需要进行大量更改。 我会将此添加到路线图中，但要注意这一点。