Vérification quotidienne des rappels

Version métier : voir Vérification quotidienne des rappels.

Description

Commande exécutée chaque nuit pour parcourir les Reminder arrivés à échéance et déclencher l’action associée : envoi de notification ou dispatch d’un message différé de classe virtuelle sur le bus Messenger. Le timestamp remindedAt est positionné sur chaque rappel traité pour éviter tout re-déclenchement.

Déclenchement

Planification GitLab (via pipeline_schedules API, 2026-04-23) :

• Description : Check reminders
• ID du schedule : 4083210
• Cron : 0 1 * * * (fuseau : Europe/Paris) — 01:00 Paris chaque jour.
• Branche : refs/heads/master
• État : actif
• Variable injectée : SCHEDULE_TYPE=check_reminders

Job CI : daily_check_reminders dans ci-jobs/.scheduled-ci.yml (stage daily_check_reminders). Le job se connecte en SSH à $DATABASE_SERVER_URL et exécute la commande dans le conteneur applicatif $APP_NAME.

Commande exécutée :

docker exec $APP_NAME php bin/console scheduled:reminder

Fonctionnement

1. Récupère les rappels du jour via ReminderRepository::getDailyReminders().
2. Si la liste est vide, la commande loggue No reminder to trigger et sort en SUCCESS.
3. Sinon, délègue à ReminderService::executeReminders(array $reminders) qui itère chaque rappel :
   • entityFQCN === Notification::class → executeNotificationReminder().
   • entityFQCN === VirtualClass::class → executeVirtualClassReminder() : construit un VirtualClassReminderMessage(entityId, reminderId), calcule un délai (targetDate - now) * 1000 ms et le publie sur MessageBusInterface avec un DelayStamp. Le consommateur Messenger envoie le rappel à l’heure exacte.
   • Met à jour Reminder.remindedAt = new DateTimeImmutable().
4. EntityManager::flush() persiste tous les remindedAt en fin de run.

TODO(review) : vérifier que ReminderService::executeNotificationReminder() envoie effectivement la notification — la méthode semble récupérer un repository sans déclencher d’envoi (relire src/Service/ReminderService.php).

Entités impactées

• Reminder — lecture (liste du jour) puis écriture de remindedAt.
• VirtualClass — cible possible du rappel (identifiée via entityFQCN + entityId).
• Notification — cible possible du rappel.

TODO(review) : pages modele-de-donnees/reminder, modele-de-donnees/virtual-class et modele-de-donnees/notification absentes — à créer par entity-documenter.

Gestion des erreurs

• Aucune exception dédiée. Une erreur pendant executeReminders (ex. Symfony\Component\Messenger\Exception\ExceptionInterface) remonte telle quelle : Sentry la capture, le job GitLab échoue (exit ≠ 0), les Reminder non traités gardent remindedAt = null et seront retentés à la prochaine exécution quotidienne.
• Pas de retry applicatif — seul le bus Messenger peut retenter la consommation du VirtualClassReminderMessage.

Dépendances externes

• RabbitMQ (bus Messenger Symfony) — transport du VirtualClassReminderMessage avec DelayStamp.
• MariaDB — lecture/écriture des Reminder.

Observabilité

• Logs : GitLab > Build > Pipelines > daily_check_reminders (sortie SSH + echo PHP).
• Alerting : Sentry capture les exceptions PHP remontées par la commande.

TODO(review) : confirmer le transport Messenger utilisé (par défaut async?) et la queue RabbitMQ dans config/packages/messenger.yaml.

Références code

• Commande : src/Command/Scheduled/ReminderCheckCommand.php
• Job CI : ci-jobs/.scheduled-ci.yml (job daily_check_reminders)
• Services : App\Service\ReminderService
• Repository : App\Repository\ReminderRepository::getDailyReminders()
• Handlers / Messages : App\Message\VirtualClassReminderMessage (consommé par le worker Messenger)