Development #20491
wscall ne devrait pas notifier ou enregistrer quand il s'agit d'erreur application (err:1)
0%
Description
La case à cocher "notifier en cas d'erreur" envoie une traceback.
Mais il y a aujourd'hui deux types d'erreurs :- les erreurs réseau, json mal formé, 403, 404, 500, etc : ce sont de vraies grosses erreurs, car un webservice interrogé par wcs doit toujours répondre 200
- l'autre erreur c'est app_error (err != 0 ou header x-error-code) et y'a pas de raison de tracebacker sur ça.
Exemple classique : recevoir une trace quand une réservation chrono est refusée parce qu'il n'y a plus de place (ça doit être géré dans le workflow, "silencieusement")
Fichiers
Révisions associées
Revert "wscall: do not notify or record applications errors (#20491)"
This reverts commit a1966769a3628c9d20f618063bbf1a21200d3087, pushed by mistake
Historique
Mis à jour par Thomas Noël il y a plus de 6 ans
- Fichier 0001-wscall-do-not-notify-or-record-applications-errors-2.patch 0001-wscall-do-not-notify-or-record-applications-errors-2.patch ajouté
- Sujet changé de wscall ne devrait pas notifier (notify_on_errors) quand il s'agit d'erreur application (err:1) à wscall ne devrait pas notifier ou enregistrer quand il s'agit d'erreur application (err:1)
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Avec ce patch, pas de traceback ni d'enregistrement sur les erreurs applicatives (y'a pas de quoi tracebacker, quand à l'enregistrement on l'a dans workflow_data de toute façon)
Mis à jour par Frédéric Péters il y a plus de 6 ans
... ça doit être géré dans le workflow.
Et ce n'est pas en rendant silencieux le fait que ça ne l'est pas que ça va l'être.
Le workflow doit être configuré pour faire un saut en cas d'erreur applicative, tant qu'il ne le fait pas, le seul moyen de capter une erreur, c'est la notification.
Le patch qu'il faut c'est celui qui n'envoie pas d'email aux admins en cas d'erreur de paramétrage, qui prévient plutôt la personne responsable technique du workflow, par mail (si jamais on en avait un) ou en rendant l'erreur disponible via le web (ce que ça fait déjà, mais qui est branché sur la notification email).
Mis à jour par Thomas Noël il y a plus de 6 ans
- Statut changé de En cours à Rejeté
Ouaich, mauvaise solution au problème.
Mis à jour par Frédéric Péters il y a plus de 6 ans
Oui, il faut améliorer la remontée des erreurs vers l'administrateur fonctionnel, particulièrement dans les informations qui lui sont communiquées (voir par exemple: #17277, je vais en créer un autre pour les remontées des appels webservice).
Mis à jour par Benjamin Dauvergne il y a plus de 6 ans
Frédéric Péters a écrit :
... ça doit être géré dans le workflow.
Et ce n'est pas en rendant silencieux le fait que ça ne l'est pas que ça va l'être.
Le workflow doit être configuré pour faire un saut en cas d'erreur applicative, tant qu'il ne le fait pas, le seul moyen de capter une erreur, c'est la notification.
Le patch qu'il faut c'est celui qui n'envoie pas d'email aux admins en cas d'erreur de paramétrage, qui prévient plutôt la personne responsable technique du workflow, par mail (si jamais on en avait un) ou en rendant l'erreur disponible via le web (ce que ça fait déjà, mais qui est branché sur la notification email).
Je plussoie, est-ce que ça vous paraîtrait juste de pouvoir paramétrer un ou des rôles comme responsable technique d'un workflow/formulaire ? Genre le rôle "Administrateurs fonctionnels", ou alors par catégorie, si on trouve un tel rôle on le notifie, sinon on notifierai un rôle globale "Responsable technique" paramétré dans /settings/ sur la page des paramètres de Debug.
wscall: do not notify or record applications errors (#20491)