Vie privée : Supprimer les emails des candidats de Brevo

[vincentporte]

🤔 Pourquoi ?

Supprimmer les emalis des candidats lors de leur archivage, en appelant l'API Brevo, sans générer de contention avec la commande notify_archive_jobseekers

🍰 Comment ?

• mutualisation de BrevoClient et ajout de la méthode de suppression
• appel de tâches unitaires pour chaque email à supprimer par la méthode de suppression delete_contacts
• appel de la méthode de suppression dans notify_archive_jobseekers

[notion-workspace]

Vie Privé: suppression des emails de la liste des candidats Brevo lors de leur archivage

[rsebille]

La PR étant en brouillon j'ai fait des commentaires généraux donc ils ne sont pas forcément cohérents entre-eux :).

Remarques générales

EmailWaitingForExternalDeletionAdmin()

J'ai un peu l'impression qu'on fait une queue persistante mais ultra-spécialisé, donc je me demande si ça serais pas "mieux" d'implémenter un storage personnalisé dans huey 🤔 en prenant comme exemple leur SqliteStorage.

Sinon je pense qu'on pourrais au moins rendre la classe plus générique afin de pouvoir gérer d'autre type de tâche et ne pas soit dupliquer ce genre de table ou avoir à faire une migration dans le futur 🤷.

notify_archive_jobseekers.py

Pas super convaincu de découpler par défaut la suppression dans le service distant de celui en local, je m'attendais un peu à qu'on essaye en synchrone et si erreur alors on met pour plus tard.

Ce qui d'ailleurs me fait me demander si on ne veux pas forcer le couplage entre la suppression dans les services externes avec celle en interne, un peu en mode "supprimé partout ou nul part".

delete_emails_from_brevo.py

Je pense qu'il manque un mécanisme pour les réessais, un last_try_at et tries_counter pourrais sans doute faire le boulot.

[xavfernandez]

Là quand on supprime un candidat, on met l'email dans notre redis et on croise fort les doigts pour que l'API de Brevo soit rapidement dispo avant notre prochain redémarrage de redis.
Et quand on redémarrera notre redis (pour une mise à jour ou autre) il faudra penser à arrêter le cron d'archivage et attendre que les taches huey soient toutes purgées (ou les dumper puis restaurer) avant de l'arrêter.
Cela me semble très fragile 😬
Donc plutôt en faveur de l'ancien modèle EmailWaitingForExternalDeletion, idéalement généralisé soit via un modèle maison, soit via un PostgresStorage (comme initialement suggéré par Romain).

[vincentporte]

02/06/2025, réunion de travail avec @francoisfreitag et @rsebille : décisions

• ne plus contraindre cette PR à Stabilité: utiliser la DB Postgres en tant que Task Queue Backend #6125, car les données de Redis sont persistantes. Il y a donc peu de risque de perte de données,
• allongement du délai de rejeu des tâches à 3 mois associé à un message dans sentry via le logger tous les 100 rejeux pour garder la visiblité sur les tâches en échec pour des causes non attrapées. (edited)

[francoisfreitag]

un message dans le logger

Warning/error dans Sentry*

[tonial]

Ça me va.
Je pense qu'il faudra prévoir une carte pour gérer un nettoyage de brevo pour les utilisateurs qui changent d'email, mais ce n'est lié à ce changement, donc tu peux lire puis ignorer le commentaire qui en parle 😝

[tonial]

Une bonne manière d'être sur de ne pas se louper :D

Je suis en train de me dCela dit, je me demande si une autre solution ne serait pas de gérer la suppression des emails depuis la commande de synchronisation.
On pourrait lister les candidats dans brevo et supprimer ceux qui ne sont plus dans notre DB 🤔
Après, vu le nombre de candidats, ça pourrait être un cron qui ne tourne qu'une fois par mois, et ça permettrait de réduire la durée de cette tâche ?
Ça ne remplacera sans doute pas cette tâche asynchrone, donc c'est plus une amélioration qu'on pourrait faire à côté (et qui permettra également de gérer les changements d'email de candidats).

[francoisfreitag]

Peut-être combiner ce test avec le test de retries pour vérifier que la tâche est réessayée tant qu’elle est en erreur.

[vincentporte]

J'ai conservé des tests appelant directement delete_contact pour tester les exceptions levées, et un appelant la méthode asynchrone async_delete_contact pour tester les retries.
Huey semble ne pas propager les exceptions levées dans les méthodes décorées, nous avons accès uniquement aux logs, donc sans certitude sur la présence d'un raise.
Peut-être une optimisation pourra être apportée plus tard.