Cron: handle error from OVH when creating email

[polomarcus]

#372

[jdauphant]

Si le job crash en continue, on aura un point d'alerte ?

[jdauphant]

Je ne suis pas sûr que ça résolve le problème.
On a OVH qui renvoit une erreur 500, qu'est-ce qu'on fait ?

Le comportement avant la PR

C'est de crasher -> l'app ne peut pas fonctionner.
Scalingo nous alerte et relance le job -> ça redémarre et on est au courant

La solution adopté dans la PR

Déplacer l'erreur dans les logs (ce n'est pas mettre un peu la poussière sous le tapis de log ?)
Il n'y a plus d'alerte, le job est arrété silencieusement -> Je vois une régression ( Après je me trompe peut être vous avez mis en place une veille des logs entre vous pour vérifier ^^)

J'aurais plutôt vu, comme solutions :

• On ne change rien, l'erreur n'est pas assez fréquente, il y a un système de relance par Scalingo. On peut en profiter pour signaler l'erreur au support OVH
  Ou
• On relance le call en échec (plutôt sur les GET) et on lance une exception uniquement au 2 ou 3 ème essai sur l'appel

My 2 cents

[alemangui]

@jdauphant en effet, le 500 d'OVH n'est pas permanent, ça arrive de temps en temps et disparaît dans l'itération suivante.

Par contre, je ne suis pas sur que le crash du cron soit souhaitable dans ce cas. Ama, la tâche de cron doit pouvoir échouer gracieusement dans ce cas et logger l'erreur sans que le processus lance une exception non gérée (et par conséquent envoie un email aux admins Scalingo). Sauf erreur de ma part dans le cron du marrainage il y a une approche similaire.

Je serais plutôt dans le camp de soit faire de relances ou de mettre en place un système de suivi de logs. On avait discuté d'un Sentry dans #143, ce serait peut être l'occasion de s'y attaquer ?

[jdauphant]

On n'a pas le sentry pour le moment, on dépend des rapports de crashs de scalingo. Ça n'aurait pas du être fait en premier ? Une fois mis en place, cette PR fait plus de sens.
Est-ce que sentry marche aussi dans ce cas là en JS, tu sais comment ça marche ? ça parse le log de sortie ?

On pourrait rendre le job plus robuste sur cette erreur en particulier en traitant les erreurs aussi au bon niveau pour le moment.

[alemangui]

Ça marche, on pourra faire des modifs dans cet enroit (ou faire un revert) le temps que Sentry soit en place.

Il y a moyen de capturer le console.error dans Sentry une fois que ça sera mis en place via le CaptureConsole, qui pourrait être configuré pour capturer seulement la méthode error, quelque chose comme :

Sentry.init({
    integrations: [
        new CaptureConsole({
            levels: ['error']
        })
    ]
})