Produits Entr'ouvert » w.c.s.

On ne veut pas charger sentry d'erreurs métier; quelles erreurs vois-tu passées à record_error() et que tu voudrais/préférereais dans sentry ?

Frédéric Péters a écrit :

On ne veut pas charger sentry d'erreurs métier; quelles erreurs vois-tu passées à record_error() et que tu voudrais/préférerais dans sentry ?

Le problème c'est qu'on a pas que des erreurs métiers, sur les expressions on a effectivement beaucoup de bêtises au niveau des expressions/gabarits mais dès que la trace atteint des couches basses comme les requêtes à postgres, par exemple, on est plus sur du métier et c'est caché dans les LoggedError; au SICTIAM typiquement la plupart des erreurs de connexion à la base sont dans des LoggedError (ce n'est pas un excellent exemple puisqu'on en voit aussi dans sentry via la commande cron¹, mais on peut imaginer n'importe quoi comme exception dans le code de w.c.s. qui casserait dans une condition ou gabarit sans qu'on puisse dire que c'est métier et sans que ça apparaisse ailleurs); alors oui il y a aussi les notifications par mail, mais on en fait plus qu'une, qu'on peut rater/oublier, alors qu'avec sentry on a l'histogramme dans le temps et le décompte.

Aussi je trouve que sentry nous donne les avantages des LoggedError (possibilité de lien vers le contexte, formdata, formdef, workflow, expression, décompte du nombre d'erreurs, etc...), une interface sympa et que ça centralise les erreurs pour tous nos clients ou pour un client particulier (on peut voir les erreurs transversalement entre w.c.s et passerelle ou combo et w.c.s.). Et dernier argument ça permet de jeter get_logger().error(...) à la poubelle pour n'avoir qu'un seul mode de fonctionnement.

Et dernière chose, on pourrait vraisemblablement établir une profondeur de trace qui détermine si c'est métier ou pas, à partir de 2 frames par exemple, on est plus vraiment dans l'expression, il faudrait tester (c'est un peu l'objet du ticket aussi).

¹ https://sentry.entrouvert.org/entrouvert/sictiam/issues/48076/?query=is%3Aunresolved

Je veux bien le propos "trop bas ça devrait sortir du cadre LoggedError et être capté comme étant une erreur technique" mais il ne faut pas attacher ce propos à Sentry.

Cela étant, pour redonner le contexte ça part d'une erreur de configuration système sur une plateforme externe, qui a fait que les traces ne nous étaient pas envoyées. Partir de là pour déclencher des changements (ou même réflexions) de fond dans le traitement général des erreurs, je ne pense pas que ça soit opportun.

(il y a selon moi des développements bien plus important ailleurs)