Sentry-javascript: Devolver una promesa de los principales métodos de captura* de la API

Gracias por resaltar esto, para dejar en claro que no es completamente sincrónico, el "transporte" se ejecuta en segundo plano. Entonces, estrictamente hablando, no se garantiza que el evento llegue a Sentry.

El eventId se genera en el SDK localmente y se usará para ingerir el evento en el servidor.

Actualizaremos nuestros documentos para dejar esto claro.

Ok, solo para aclarar, es necesario implementar lo que se describe aquí: https://docs.sentry.io/error-reporting/configuration/draining/?platform=node

¿Es esto correcto, @HazAT?

@rhyek Corrent, si quiere asegurarse de que todo se envíe, puede esperar a que se envíe todo para asegurarse de que todo se envíe.

¿No sería mejor simplemente exponer la promesa de los métodos capture* ? La API sería más clara ya que devolver una promesa les permite a los usuarios saber que tienen que await para asegurarse de que se envíe el evento o simplemente disparar y olvidar con la esperanza de que se envíe. Tanto close como flush son métodos de utilidad ambigua que intentan hacer sincrónico algo que se ha considerado asincrónico. Además, ambos métodos están totalmente rotos: de hecho, hay bastantes peculiaridades (diría que es un error, pero probablemente esto dependa del punto de vista de la persona que los mira):

• el propósito de los timeout pasados ​​a flush es nulo porque no es respetado por el transporte al interrumpir el envío de las solicitudes. Simplemente resuelve la promesa devuelta en false cuando expira el temporizador. Todavía me pregunto la utilidad de tal código y comportamiento...
• el método flush devuelve una nueva promesa cada vez que se llama que se resuelve tan pronto como se alcanza el timeout . Hay dos problemas: todo el código ejecutado por setInterval es extremadamente lento, al menos en mis pruebas en la consola del navegador, y la promesa se resolvió muchos segundos después de que expirara el tiempo de espera. El segundo y más importante problema es que el código de la función _isClientProcessing borra el tiempo de espera cada vez que se llama, así que si alguien está haciendo algo como Promise.all([fush(), flush()]) (no sé por qué debería hacerlo pero dado que la API devuelve una nueva promesa cada vez que puede tener la tentación de hacerlo), dicha promesa nunca se resolverá.

Corriente, si desea asegurarse de que todo se envíe, puede esperar a que se envíe todo para asegurarse de que todo se envíe.

Incorrecto, vea mis puntos anteriores para comprender por qué, incluso esperando el color, no puede estar seguro de que todo se envíe. Diría que dicho diseño de API está totalmente roto y realmente no puedo entender por qué no dejar al usuario la opción de esperar las promesas que representan el envío de un evento en lugar de intentar construir una API de apagado que ni siquiera puede funcionar para todos. idiomas en los que debería funcionar la API unificada

Creo que tener acceso a una promesa que se resuelve cuando el evento es finalmente
enviado además de los otros métodos descritos en este hilo hace un
mucho sentido

El sábado 11 de mayo de 2019 a las 12:29 Stefano Arlandini [email protected]
escribió:

¿No sería mejor simplemente exponer la promesa de la captura?*
¿métodos? La API sería más clara ya que devolvería una promesa para que los usuarios sepan que
tienen que esperar para estar seguros de que el evento se envía o simplemente
disparar y olvidar con la esperanza de que se envíe. Tanto close como flush son métodos de
utilidad ambigua que intenta hacer sincrónico algo que ha sido
pensar en ser asíncrono. Además, ambos métodos están totalmente rotos: en
De hecho, hay bastantes peculiaridades (diría que es un error, pero
probablemente esto dependa del punto de vista de la persona que los mira):

• el propósito del tiempo de espera pasado para vaciar es nulo porque no es
  respetado por el transporte interrumpiendo el envío de las solicitudes. Eso
  simplemente resuelve la promesa devuelta en falso cuando expira el temporizador.
  Todavía me pregunto la utilidad de tal código y comportamiento...
• el método de descarga devuelve una nueva promesa cada vez que se llama así
  se resuelve tan pronto como se alcanza el tiempo de espera. Hay dos problemas:
  todo el código ejecutado por setInterval es extremadamente lento, al menos en
  mis pruebas en la consola del navegador, y la promesa resolvió un montón de
  segundos después de que expirara el tiempo de espera. El segundo y más importante problema es
  que el código de la función _isClientProcessing borra el tiempo de espera
  cada vez que se llama, así que si alguien está haciendo algo como Promise.all([fush(),
  flush()]) (No sé por qué debería hacerlo, pero dado que la API devuelve
  una nueva promesa cada vez que se sienta tentado a hacerlo), entonces tal promesa
  nunca se resuelva.

Corriente, si desea asegurarse de que todo se envíe, puede esperar a que se enjuague
para asegurarse de que todo se envía.

Incorrecto, vea mis puntos anteriores para entender por qué incluso esperando que lo enjuague
No se puede estar seguro de que se envíe todo. Diría que tal diseño de API es
totalmente roto y realmente no puedo entender por qué no dejar al usuario el
opción de esperar las promesas que representa el envío de un evento
en lugar de intentar construir una API de cierre que ni siquiera puede funcionar para todos
idiomas en los que debería funcionar la API unificada

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/getsentry/sentry-javascript/issues/2049#issuecomment-491533914 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAFLTSVSICZ7Y26UHCSMKWLPU4GATANCNFSM4HKUJ5ZQ
.

También diría que no espero que un método devuelva un resultado para ejecutar algo en segundo plano, ya que esto es una fuente de confusión para los usuarios (y la pregunta principal de este problema, por supuesto). En cambio, si se devuelve una promesa, está claro que es solo un marcador de posición para algo que vendrá en el futuro y que aún no está listo. Obviamente, la elección de esperar o simplemente disparar y olvidar depende del usuario. Además, dado que la identificación del evento se genera localmente (no veo ninguna razón para hacerlo por cierto), puede usar algo (porque se devuelve de inmediato) que no es válido porque, por alguna razón, el transporte no pudo enviar el evento y usted no Ni siquiera lo sé

Hemos tenido bastantes problemas con Sentry desde que actualizamos a @sentry/node , probablemente volveremos a raven-node hasta que haya una solución mejor.

Tener que drenar colas en tiempos de espera arbitrarios al final de cada ejecución sin servidor definitivamente se siente más como un truco y no como una solución. 🤔

Para aquellos que buscan más ejemplos de lo que podría funcionar, encontré algunas de las soluciones dentro del n. ° 1449 útiles sobre el enjuague y demás, también discuten mucho sobre este problema.

(Están enfocados en lambdas y serverless, pero los mismos conceptos probablemente también funcionen en otros entornos, ya que es el enfoque de descarga).

Definitivamente interesado en que haya una mejor manera en algún momento que no implique tirar de la cadena cada vez.

Completamente de acuerdo con lo que se dice en este hilo, en mi opinión, es realmente confuso tener un método síncrono que oculta la asincronía en segundo plano.
Tal vez el equipo centinela tenga una muy buena razón para hacerlo de esta manera, de todos modos, agradecería mucho una actualización de la documentación.

@cibergarri Creo que la razón de esto es que el eventId se puede devolver de inmediato sin bloquear el código de usuario en una llamada de red potencialmente lenta a Sentry Apis. Estoy de acuerdo en que es confuso devolver un valor de una API asíncrona y potencialmente conduce a la pérdida silenciosa de errores en contextos de ejecución sin servidor que no permanecen el tiempo suficiente para las llamadas de la capa de transporte asíncrono. Una solución sería dividir la función en dos para que un usuario deba optar por el comportamiento asincrónico, por ejemplo

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

O como un parámetro, por ejemplo

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

El ID del evento siempre se genera en el cliente, por lo que la API asíncrona o sincronizada no importa y, en consecuencia, no es un buen indicador de si un evento se ha enviado o no de verdad (otro problema, en mi opinión). También propuse hace mucho tiempo para PHP SDK una solución similar que implicaba tener métodos sincrónicos y asincrónicos para cada método capture* pero fue rechazada. No entendí completamente la verdadera razón por la que Unified API quiere ocultar la asincronía y los desarrolladores no quieren exponer una promesa, pero me pareció que no estaban tan abiertos a cambiar esto.

Lamentablemente, este problema hizo que me alejara de Sentry, ya que hacía que los errores de seguimiento en entornos sin servidor fueran demasiado propensos a errores. (Oh, la ironía.)

capture*Async métodos

¿Podemos obtener una actualización sobre esto?

@marcospgp que te gustaría saber exactamente? Todo lo que escribió Daniel sigue siendo cierto hasta el día de hoy.

Creo que aparte de la documentación, está bastante claro a partir de las reacciones en los comentarios y los comentarios mismos que a los usuarios les gustaría tener acceso a las promesas, y no hay una buena razón para no permitir esto en mi humilde opinión.

Desafortunadamente, no sucederá antes del lanzamiento de v6, ya que es un cambio radical en nuestras API principales y requeriría muchos cambios. Sin embargo, agregaré esto a la hoja de ruta para mantener esto en cuenta.