[bug ?] Mise à jour de calendrier non instantané

Hello,
Cette semaine j’ai modifié un de mes calendriers pour le chauffage : en gros j’ai supprimé tous les évènements.
La synchro dans Gladys ne s’est pas faite, aucun changement.
J’ai forcé la synchro mais toujours aucun changement.
J’ai laissé tourné mais rien de plus.
Et ce matin j’ai enlevé le partage de ce calendrier (au cas où), j’ai resauvegardé la configuration et relancer une synchro et les évènements ont disparu.

Est-ce qu’il peut y avoir un soucis avec les évènements répétitifs ou une synchro qui ne se fait pas/plus en automatique ?

J’ai mes logs de dispo pour analyse si besoin.

Salut @mutmut, merci pour le retour.

Je veux bien les logs pour donner tout ça à Claude pour analyse :slight_smile:

Merci beaucoup @mutmut pour le signalement et pour les logs, ils ont permis de mettre le doigt sur un vrai bug :folded_hands:

Ce qu’il se passait

Tes logs montrent que la synchro CalDAV tournait bien toutes les 30 minutes, sans jamais rien appliquer :

09:31:33  CalDAV : Found calendar Chauffage
09:31:33  CalDAV : Found 4 calendars.

…et rien d’autre pendant 17 heures d’affilée. Aucune erreur, mais aucune modification non plus.

Ton intuition sur les événements répétitifs était la bonne. Dans Gladys, un événement récurrent est enregistré sous forme d’une ligne par occurrence (ton calendrier Chauffage en contient 575). Or, quand le serveur CalDAV signalait la suppression d’un événement, Gladys ne le supprimait que s’il trouvait exactement une occurrence correspondante. Pour un événement récurrent il y en avait des centaines, donc la condition n’était jamais remplie et rien n’était supprimé. Comme ce cas ne produisait aucune ligne de log, la synchro paraissait ne plus tourner du tout.

Deux problèmes aggravants ont été trouvés au passage :

  1. Gladys marquait le calendrier comme « à jour » avant d’avoir réellement appliqué les changements. Une fois la suppression ratée, ces modifications étaient donc perdues définitivement, et les synchros suivantes ne les redemandaient plus jamais. C’est exactement pour ça que forcer la synchro ne changeait rien : seul un réimport complet (ce que fait la sauvegarde de la configuration) pouvait s’en sortir, et tu avais trouvé le bon contournement.
  2. Quand une règle de récurrence était raccourcie ou qu’une occurrence était retirée, les anciennes occurrences restaient en base indéfiniment.

Ce qui a été corrigé

  • Toutes les occurrences d’un événement récurrent supprimé sont bien supprimées.
  • Le ctag / sync token n’est enregistré qu’après que les changements ont été appliqués : plus de calendrier bloqué définitivement en cas d’échec.
  • Les occurrences qui n’existent plus côté serveur sont nettoyées.
  • Les calendriers sont synchronisés dès le démarrage du service, au lieu d’attendre 30 minutes (visible dans tes logs : service démarré à 09:01:33, première synchro à 09:31:33).
  • Les logs indiquent désormais aussi le nombre d’événements supprimés, pour que ce genre de souci soit visible.

Le correctif est ici : Improve CalDAV sync: handle deleted events and defer ctag updates by Pierre-Gilles · Pull Request #2712 · GladysAssistant/Gladys · GitHub

À noter : la synchro CalDAV reste basée sur un rafraîchissement toutes les 30 minutes, elle ne peut donc pas être instantanée au sens strict. Mais une modification devrait maintenant être prise en compte à la synchro suivante, sans jamais rester bloquée.

Le correctif est live dans Gladys Assistant 4.84