Produits Entr'ouvert » w.c.s.

Je ne vois pas pourquoi tu spécialises ainsi, en fait on a aucune exception ne remonte dans sentry dès qu'elle passe dans le cas Exception ici, c'est le cas Exception qu'il faut chopper.

• quand c'est dans un thread
• dans le cas template géré à la main
• dans le ou ça arrive après comme un middleware django, tant que ça remonte au handler de requête c'est bon

En fait on en manque un bon paquet (et il y a aussi tout ce qui est logger avec logged_errors qui ne remonte pas, mais ça c'est plus délicat).

Benjamin Dauvergne a écrit :

En fait on en manque un bon paquet (et il y a aussi tout ce qui est logger avec logged_errors qui ne remonte pas, mais ça c'est plus délicat).

C'est assez normal à mon sens : les logged_errors sont destinées au administrateurs fonctionnels et ne sont donc pas destinées à remonter dans sentry.

Thomas Noël a écrit :

Benjamin Dauvergne a écrit :

En fait on en manque un bon paquet (et il y a aussi tout ce qui est logger avec logged_errors qui ne remonte pas, mais ça c'est plus délicat).

C'est assez normal à mon sens : les logged_errors sont destinées au administrateurs fonctionnels et ne sont donc pas destinées à remonter dans sentry.

On est HS (je demande juste à chopper toutes les Exception et pas juste celle de psycopg2 au niveau du gestionnaire de requête) mais:

En théorie ce serait super, en pratique je ne suis pas certain qu'on soit exclusivement sur des erreurs de niveau fonctionnel "admin fonctionnel" et que dans ce cas le délais de traitement soit raisonnable, "l'admin fonctionnel le repère, il ouvre un ticket, etc...". Les traces qu'on reçoit via sentry/mail (voir le souci de date) on les traite plus vite en général (le cas dmy/mdy par exemple).

Il ne faut pas remonter les "logged errors" vers Sentry. Tout patch qui ferait ça serait rejeté.

compat:

Il y a peut-être la fausse idée comme quoi le préfixe d'un message de commit devrait correspondre au nom de fichier. Ce n'est pas le cas. "compat:" ça serait par exemple pour indiquer un commit qui touche à une question de compatibilité. Ça n'est pas le cas ici.

add foreground

tu as sans doute voulu écrire frontoffice.

_~~

Sur le patch; le traitement des exceptions se fait actuellement dans finish_failed_request, voire log_internal_error, il ne faut pas avoir un bout pour sentry dans compat.py et un bout pour les mails ailleurs.

Pour boucler sur le début de mon commentaire : compat indique que ce fichier est une couche de compatibilité, entre django et quixote, il faut éviter d'y ajouter des fonctionnalités.

Alors oui il y a actuellement déjà

            if can_sentry():
                sentry_sdk.capture_exception(exc)

dans ce fichier pour une autre situation.

Mais celle-là aurait également été gérée dans finish_failed_request() ce ticket n'existerait même pas.

Nicolas Roche a écrit :

faut regarder le champ mechanism

(je ne l'ai pas trouvé)

C'est uniquement sur les trace qui ne sont pas capturées par un mécanisme explicite de sentry (donc pas les trace dans les templates justement), ça en laisse quelques unes quand même.

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

Alors oui il y a actuellement déjà

[...]

dans ce fichier pour une autre situation.

Mais celle-là aurait également été gérée dans finish_failed_request() ce ticket n'existerait même pas.

En plus clair je crois que Fred t'indique de travailler plutôt dans finish_failed_request() et de supprimer les références explicites à sentry ailleurs (l'exception est disponible dans finish_failed_request via sys.exc_info).

Il faut faire ça après le

        if exc_type is NotImplementedError:

basiquement, au niveau de log_internal_error.

Automatic expiration