fix(blog): n'acquitter les GUID RSS qu'après une livraison XMPP confirmée #12

New Issue

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

AntoineVe commented

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

Constat

fetch_blog_step() ajoute les GUID reçus à BlogRSSState et met à jour l'état HTTP avant que le pipeline tente d'envoyer le message XMPP.

Un article est donc définitivement considéré comme traité lorsque :

aucun canal XMPP n'est configuré ;
l'exécution est un dry-run ;
send_step() retourne False ;
l'envoi lève une exception, convertie en avertissement dégradé par PipelineRunner.

Dans ces cas, l'article ne sera plus retourné lors de l'exécution suivante, bien qu'aucune livraison n'ait été confirmée. La préférence actuelle pour éviter les doublons cause ainsi une perte silencieuse d'information.

Proposition

Séparer la récupération de l'acquittement :

récupérer les nouveaux articles sans modifier les GUID connus ;
tenter la livraison ;
n'enregistrer les GUID livrés qu'après confirmation explicite de l'envoi.

Conserver les validateurs HTTP (ETag/Last-Modified) dans une sémantique distincte et documenter le comportement voulu en absence de canal ou en dry-run. Une répétition après panne est préférable à une perte ; le message doit donc être tolérant aux doublons éventuels.

Critères d'acceptation

Un envoi XMPP réussi acquitte exactement les GUID des articles livrés.
Une erreur, un retour False, une absence de canal ou un dry-run laissent les articles récupérables au run suivant.
Un arrêt entre récupération et envoi ne fait pas perdre les articles.
L'état persistant reste atomique et les redémarrages conservent la sémantique choisie.
Les tests couvrent succès, exception, retour False, canal absent, dry-run et reprise après redémarrage.
La documentation d'exploitation précise cette garantie et le comportement éventuel de rediffusion.

Périmètre

Source RSS, orchestration de l'acquittement et documentation ; la politique de rétention à long terme des GUID peut faire l'objet d'un ticket séparé.

## Constat `fetch_blog_step()` ajoute les GUID reçus à `BlogRSSState` et met à jour l'état HTTP avant que le pipeline tente d'envoyer le message XMPP. Un article est donc définitivement considéré comme traité lorsque : - aucun canal XMPP n'est configuré ; - l'exécution est un dry-run ; - `send_step()` retourne `False` ; - l'envoi lève une exception, convertie en avertissement dégradé par `PipelineRunner`. Dans ces cas, l'article ne sera plus retourné lors de l'exécution suivante, bien qu'aucune livraison n'ait été confirmée. La préférence actuelle pour éviter les doublons cause ainsi une perte silencieuse d'information. ## Proposition Séparer la récupération de l'acquittement : 1. récupérer les nouveaux articles sans modifier les GUID connus ; 2. tenter la livraison ; 3. n'enregistrer les GUID livrés qu'après confirmation explicite de l'envoi. Conserver les validateurs HTTP (ETag/Last-Modified) dans une sémantique distincte et documenter le comportement voulu en absence de canal ou en dry-run. Une répétition après panne est préférable à une perte ; le message doit donc être tolérant aux doublons éventuels. ## Critères d'acceptation - Un envoi XMPP réussi acquitte exactement les GUID des articles livrés. - Une erreur, un retour `False`, une absence de canal ou un dry-run laissent les articles récupérables au run suivant. - Un arrêt entre récupération et envoi ne fait pas perdre les articles. - L'état persistant reste atomique et les redémarrages conservent la sémantique choisie. - Les tests couvrent succès, exception, retour `False`, canal absent, dry-run et reprise après redémarrage. - La documentation d'exploitation précise cette garantie et le comportement éventuel de rediffusion. ## Périmètre Source RSS, orchestration de l'acquittement et documentation ; la politique de rétention à long terme des GUID peut faire l'objet d'un ticket séparé.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#12