Sentry-javascript: Renvoyer une promesse à partir des principales méthodes de capture* de l'API

Merci d'avoir souligné cela, pour préciser que ce n'est pas entièrement synchrone, le "transport" s'exécute en arrière-plan. Donc, à proprement parler, il n'est pas garanti que l'événement touche Sentry.

Le eventId est généré localement dans le SDK et sera utilisé pour ingérer l'événement sur le serveur.

Nous mettrons à jour nos documents pour que cela soit clair.

Ok, donc juste pour clarifier, il faut bien implémenter ce qui est décrit ici : https://docs.sentry.io/error-reporting/configuration/draining/?platform=node

Est-ce correct, @HazAT ?

@rhyek Corrent, si vous voulez vous assurer que tout est envoyé, vous pouvez attendre flush pour vous assurer que tout est envoyé.

Ne vaudrait-il pas mieux simplement exposer la promesse des méthodes capture* ? L'API serait plus claire puisque le retour d'une promesse informerait les utilisateurs qu'ils doivent await pour être sûr que l'événement est envoyé ou simplement tirer et oublier en espérant qu'il soit envoyé. Tant close que flush sont des méthodes d'utilité ambiguë qui essaient de rendre synchrone quelque chose qui a été considéré comme asynchrone. De plus, ces deux méthodes sont totalement cassées : en fait, il y a pas mal de bizarreries (je dirais que c'est un bug mais cela dépend probablement du POV de la personne qui les regarde) :

• le but du timeout passé à flush est nul car il n'est pas respecté par le transport en interrompant l'envoi des requêtes. Il résout simplement la promesse renvoyée en false lorsque le minuteur expire. Je me demande encore l'utilité d'un tel code et comportement...
• la méthode flush renvoie une nouvelle promesse à chaque appel qui est résolue dès que le timeout est atteint. Il y a deux problèmes : tout le code exécuté par setInterval est extrêmement lent, du moins dans mes tests dans la console du navigateur, et la promesse a été résolue plusieurs secondes après l'expiration du délai d'attente. Le deuxième problème, et le plus important, est que le code de la fonction _isClientProcessing efface le délai d'attente à chaque fois qu'elle est appelée, donc si quelqu'un fait quelque chose comme Promise.all([fush(), flush()]) (je ne sais pas pourquoi il devrait le faire mais puisque l'API renvoie une nouvelle promesse à chaque fois qu'il peut être tenté de le faire), une telle promesse ne sera jamais résolue.

Corrent, si vous voulez vous assurer que tout est envoyé, vous pouvez attendre flush pour vous assurer que tout est envoyé.

Incorrect, voir mes points ci-dessus pour comprendre pourquoi même en attendant le flush, vous ne pouvez pas être sûr que tout est envoyé. Je dirais qu'une telle conception d'API est totalement cassée et je ne comprends pas vraiment pourquoi ne pas laisser à l'utilisateur le choix d'attendre les promesses que représente l'envoi d'un événement au lieu d'essayer de construire une API d'arrêt qui ne peut même pas fonctionner pour tous langages où l'API unifiée devrait fonctionner

Je pense avoir accès à une promesse qui se résout lorsque l'événement est enfin
envoyé en plus des autres méthodes décrites dans ce fil fait un
beaucoup de bon sens.

Le sam. 11 mai 2019, 12:29 Stefano Arlandini [email protected]
a écrit:

Ne vaudrait-il pas mieux exposer la promesse de la capture*
méthodes ? L'API serait plus claire puisque le retour d'une promesse informerait les utilisateurs que
ils doivent l'attendre pour être sûr que l'événement est envoyé ou simplement
tirez et oubliez en espérant qu'il soit envoyé. Les deux près et flush sont des méthodes de
utilitaire ambigu qui essaie de rendre synchrone quelque chose qui a été
pensez à être asynchrone. De plus, ces deux méthodes sont totalement cassées : dans
en fait, il y a pas mal de bizarreries (je dirais que c'est un bug mais
cela dépend probablement du POV de la personne qui les regarde):

• le but du timeout passé à flush est nul car il ne l'est pas
  respecté par le transport en interrompant l'envoi des demandes. Ce
  résout simplement la promesse renvoyée à false lorsque le minuteur expire.
  Je me demande encore l'utilité d'un tel code et comportement...
• la méthode flush renvoie une nouvelle promesse à chaque fois qu'elle est appelée
  est résolu dès que le délai d'attente est atteint. Il y a deux problèmes :
  l'ensemble du code exécuté par setInterval est extrêmement lent, du moins dans
  mes tests dans la console du navigateur, et la promesse a résolu pas mal de
  secondes après l'expiration du délai d'attente. Le deuxième problème, le plus important, est
  que le code de la fonction _isClientProcessing efface le timeout
  chaque fois qu'il est appelé, donc si quelqu'un fait quelque chose comme Promise.all([fush(),
  flush()]) (je ne sais pas pourquoi il devrait le faire, mais puisque l'API renvoie
  une nouvelle promesse chaque fois qu'il peut être tenté de le faire) alors une telle promesse sera
  jamais être résolu.

Corrent, si vous voulez vous assurer que tout est envoyé, vous pouvez attendre flush
pour s'assurer que tout est envoyé.

Incorrect, voir mes points ci-dessus pour comprendre pourquoi même attendre la chasse d'eau
ne peut pas être sûr que tout est envoyé. Je dirais qu'une telle conception d'API est
totalement cassé et je ne comprends pas vraiment pourquoi ne pas laisser à l'utilisateur le
choix d'attendre les promesses que représente l'envoi d'un événement
au lieu d'essayer de créer une API d'arrêt qui ne peut même pas fonctionner pour tous
langages où l'API unifiée devrait fonctionner

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/getsentry/sentry-javascript/issues/2049#issuecomment-491533914 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAFLTSVSICZ7Y26UHCSMKWLPU4GATANCNFSM4HKUJ5ZQ
.

Je dirais également que je ne m'attends pas à ce qu'une méthode renvoyant un résultat exécute quelque chose en arrière-plan car cela est source de confusion pour les utilisateurs (et la question principale de ce problème bien sûr). Au lieu de cela, si une promesse est retournée, il est clair qu'il s'agit simplement d'un espace réservé pour quelque chose qui arrivera dans le futur et qui n'est pas encore prêt. Le choix de l'attendre ou simplement de le tirer et de l'oublier revient évidemment à l'utilisateur. De plus, étant donné que l'ID d'événement est généré localement (je ne vois aucune raison de le faire d'ailleurs), vous pouvez utiliser quelque chose (car il est renvoyé immédiatement) qui n'est pas valide car pour une raison quelconque, le transport n'a pas réussi à envoyer l'événement et vous ne je ne le sais même pas

Nous avons eu pas mal de problèmes avec Sentry depuis que nous sommes passés à @sentry/node , nous allons probablement revenir à raven-node jusqu'à ce qu'il y ait une meilleure solution.

Devoir drainer des files d'attente sur des délais d'attente arbitraires à la fin de chaque exécution sans serveur ressemble certainement plus à un piratage qu'à une solution. ??

Pour ceux qui recherchent plus d'exemples de ce qui pourrait fonctionner - j'ai trouvé certaines des solutions dans # 1449 utiles autour du rinçage et autres, ils discutent également beaucoup de ce problème.

(Ils se concentrent sur les lambdas et sans serveur, mais les mêmes concepts fonctionneraient probablement dans d'autres environnements car il s'agit de l'approche de rinçage).

Je souhaite vraiment qu'il y ait un meilleur moyen à un moment donné qui n'implique pas de rincer à chaque fois.

Entièrement d'accord avec ce qui est dit sur ce fil, IMO c'est vraiment déroutant d'avoir une méthode synchrone qui cache l'asynchronie en arrière-plan.
Peut-être que l'équipe sentinelle a une très bonne raison de procéder ainsi, de toute façon une mise à jour de la documentation serait vraiment appréciée.

@cibergarri Je pense que la raison en est que l'identifiant d'événement peut être renvoyé immédiatement sans bloquer le code utilisateur sur un appel réseau potentiellement lent à sentinelle apis. Je conviens qu'il est déroutant de renvoyer une valeur à partir d'une API asynchrone et conduit potentiellement à une perte silencieuse d'erreurs dans des contextes d'exécution sans serveur qui ne durent pas assez longtemps pour les appels de couche de transport asynchrones. Une solution serait de diviser la fonction en deux afin qu'un utilisateur doive opter pour un comportement asynchrone, par exemple

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

Ou en tant que paramètre, par exemple

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

L'ID d'événement est toujours généré dans le client, donc l'API async ou sync n'a pas d'importance et, par conséquent, ce n'est pas un bon indicateur pour savoir si un événement a été envoyé ou non pour de vrai (un autre problème imo). J'ai également proposé il y a longtemps pour le SDK PHP une solution similaire qui impliquait d'avoir à la fois des méthodes synchrones et asynchrones pour chaque méthode capture* mais elle a été rejetée. Je n'ai pas bien compris la vraie raison pour laquelle l'API unifiée veut cacher l'asyncronicité et les développeurs ne veulent pas exposer une promesse, mais il me semblait qu'ils n'étaient pas tellement ouverts à changer cela.

Malheureusement, ce problème m'a fait abandonner Sentry car il rendait les erreurs de suivi dans les environnements sans serveur trop sujettes aux erreurs. (Oh l'ironie.)

capture*Async méthodes

Pouvons-nous obtenir une mise à jour à ce sujet ?

@marcospgp que voudriez-vous savoir exactement ? Tout ce que Daniel a écrit est toujours vrai à ce jour.

Je pense que la documentation mise à part, il est assez clair d'après les réactions sur les commentaires et les commentaires eux-mêmes que les utilisateurs aimeraient avoir accès aux promesses, et il n'y a aucune bonne raison de ne pas autoriser cela à mon humble avis

Malheureusement, cela ne se produira pas avant la sortie de la v6, car il s'agit d'un changement radical dans nos principales API et nécessiterait de nombreux changements. J'ajouterai cela à la feuille de route pour que cela soit noté.