Bug #60278
toulouse_smart: les jobs de creation d'intervention en échec sur une 400 sont indéfiniment rejoués
0%
Description
Il faudrait distinguer les erreurs réseaux où l'on veut que le job soit relancé des erreurs 400/500 où l'on ne le souhaite pas.
Fichiers
Révisions associées
Historique
Mis à jour par Thomas Noël il y a plus de 2 ans
- 4xx : ne pas relancer, c'est une réponse du logiciel tiers (définitive, donc, sauf bogue dans le logiciel tiers, mais c'est un autre problème)
- 5xx : relancer, c'est une panne (timeout, crash, etc) qui va être corrigée un jour
Je mettrais quand même des limites à la répétition...
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Thomas Noël a écrit :
Dans le théorie :
- 4xx : ne pas relancer, c'est une réponse du logiciel tiers (définitive, donc, sauf bogue dans le logiciel tiers, mais c'est un autre problème)
- 5xx : relancer, c'est une panne (timeout, crash, etc) qui va être corrigée un jour
Je mettrais quand même des limites à la répétition...
C'est pas évident, une 404 peut arriver si le reverse proxy n'est plus configuré correctement ou se met à pointer sur un service qui n'est plus là (voir Oxyad), Toulouse c'est un peu des pros de ça. Je dirai que dans tous les cas il faut limiter le nombre de rejeu à 4 ou 5, quitte à clairement espacer les deux derniers, genre 1h puis 24h et ensuite bien remonter les erreurs à w.c.s. via les triggers et pas seulement les succès, à charge pour le workflow de différentier tout ça. Mais comme on a comme objectif de passer de plus en plus par des triggers on pourrait formaliser ça (trigger success, created, error, etc...)
Mis à jour par Nicolas Roche il y a plus de 2 ans
- Fichier 0001-toulouse_smart-limit-create_intervention-tries-60278.patch 0001-toulouse_smart-limit-create_intervention-tries-60278.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
il faut limiter le nombre de rejeu à 4 ou 5, quitte à clairement espacer les deux derniers, genre 1h puis 24h
Patch avec 5 essais, espacés de 5 minutes (par défaut quand les crons se relancent) sauf les 2 derniers à 1h puis 24h.
bien remonter les erreurs à w.c.s. via les triggers et pas seulement les succès
Fait , mais j'ai un doute sur le fait que le trigger remonte si le workflow est déjà dans le statut visé .
comme on a comme objectif de passer de plus en plus par des triggers on pourrait formaliser ça (trigger success, created, error, etc...)
J'ai gardé "registered" et "sent" et ajouté "failed" pour coller à ce que l'on a dans les Jobs.
Mis à jour par Nicolas Roche il y a plus de 2 ans
- Fichier 0001-toulouse_smart-limit-create_intervention-tries-60278.patch 0001-toulouse_smart-limit-create_intervention-tries-60278.patch ajouté
Fait, mais j'ai un doute sur le fait que le trigger remonte si le workflow est déjà dans le statut visé.
J'ai ajouté le nombre d'essais au champs renvoyé à wcs pour vérifier et le trigger est bien remonté.
Mis à jour par Nicolas Roche il y a plus de 2 ans
- Fichier 0001-toulouse_smart-limit-create_intervention-tries-60278.patch 0001-toulouse_smart-limit-create_intervention-tries-60278.patch ajouté
(et j'ai oublié de modifier les tests en conséquence)
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Nicolas Roche il y a plus de 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 47f7cad1eb96c4bf56ac52a0a486131f59284421
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date: Wed Jan 5 15:27:21 2022 +0100
toulouse_smart: limit create_intervention tries (#60278)
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
toulouse_smart: limit create_intervention tries (#60278)