fix(cli/deploiement): rendre les exécutions dégradées observables par la supervision #13

New Issue

AntoineVe · 2026-09-09T00:07:52+02:00

AntoineVe commented

2026-09-09 00:07:52 +02:00

Constat

Le pipeline convertit plusieurs échecs en avertissements pour poursuivre l'exécution : synchronisation CalDAV en échec, erreur XMPP, échec de comparaison ou de blog. Tant que les données Pronote ont été récupérées, PipelineRunner.run() retourne des données et la CLI retourne le code 0, après avoir seulement journalisé les erreurs.

La documentation de déploiement présente pourtant l'unité systemd en échec comme signal de supervision. Avec le contrat actuel, une perte de synchronisation CalDAV ou de notification XMPP peut donc laisser le timer/systemd dans un état réussi et ne déclencher aucune alerte basée sur le code de sortie.

Proposition

Définir puis exposer un contrat d'état de sortie permettant de distinguer :

succès complet ;
succès dégradé (avec les étapes concernées) ;
échec critique.

Les options envisageables sont un code de sortie non nul dédié aux exécutions dégradées, un mode CLI --strict, ou un statut machine-readable exploitable par la supervision. Quel que soit le choix, la documentation systemd et les logs doivent décrire le même comportement.

Critères d'acceptation

Un opérateur peut distinguer de façon fiable succès complet, succès dégradé et échec critique sans lire des logs libres.
Une erreur CalDAV et un échec d'envoi XMPP sont couverts par des tests de CLI.
Le choix est compatible avec le mode dégradé voulu : il ne doit pas empêcher les étapes ultérieures utiles.
Le dry-run possède une sémantique documentée.
Les messages de statut et de supervision restent expurgés de tout secret.
Le guide d'exploitation et le wiki de déploiement indiquent la règle effective d'alerte systemd.

Périmètre

Contrat CLI/pipeline et documentation de supervision ; pas de changement imposé sur la stratégie de repli Pronote.

## Constat Le pipeline convertit plusieurs échecs en avertissements pour poursuivre l'exécution : synchronisation CalDAV en échec, erreur XMPP, échec de comparaison ou de blog. Tant que les données Pronote ont été récupérées, `PipelineRunner.run()` retourne des données et la CLI retourne le code 0, après avoir seulement journalisé les erreurs. La documentation de déploiement présente pourtant l'unité systemd en échec comme signal de supervision. Avec le contrat actuel, une perte de synchronisation CalDAV ou de notification XMPP peut donc laisser le timer/systemd dans un état réussi et ne déclencher aucune alerte basée sur le code de sortie. ## Proposition Définir puis exposer un contrat d'état de sortie permettant de distinguer : - succès complet ; - succès dégradé (avec les étapes concernées) ; - échec critique. Les options envisageables sont un code de sortie non nul dédié aux exécutions dégradées, un mode CLI `--strict`, ou un statut machine-readable exploitable par la supervision. Quel que soit le choix, la documentation systemd et les logs doivent décrire le même comportement. ## Critères d'acceptation - Un opérateur peut distinguer de façon fiable succès complet, succès dégradé et échec critique sans lire des logs libres. - Une erreur CalDAV et un échec d'envoi XMPP sont couverts par des tests de CLI. - Le choix est compatible avec le mode dégradé voulu : il ne doit pas empêcher les étapes ultérieures utiles. - Le dry-run possède une sémantique documentée. - Les messages de statut et de supervision restent expurgés de tout secret. - Le guide d'exploitation et le wiki de déploiement indiquent la règle effective d'alerte systemd. ## Périmètre Contrat CLI/pipeline et documentation de supervision ; pas de changement imposé sur la stratégie de repli Pronote.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#13