Rendre l'import idempotent et sûr sous concurrence #7

New issue

Open

opened 2026-04-12 18:05:43 +00:00 by thibaud-lclr · 0 comments

thibaud-lclr commented

2026-04-12 18:05:43 +00:00

(Migrated from gitea.lclr.dev)

1. Le souci

L'import asynchrone découpe les films en batchs et peut traiter plusieurs messages en parallèle. Aujourd'hui, la déduplication repose surtout sur des vérifications applicatives (findOneBy, count) sans contraintes uniques alignées en base.

Conséquences possibles :

création de doublons movie, actor, movie_role, award_type, award ;
collisions entre workers avec faux échecs d'import ;
comportement non déterministe si plusieurs workers traitent des films proches en même temps.

2. Proposition de solution

Rendre le pipeline explicitement idempotent et robuste aux courses concurrentes.

Pistes :

ajouter des contraintes uniques côté base sur les clés naturelles pertinentes ;
capturer les collisions d'unicité côté handlers/importers ;
faire en sorte qu'un retry Messenger n'aggrave jamais l'état des données ;
éviter les count() de présence comme seul garde-fou.

3. Proposition d'implémentation

Schéma

movie.ltbxd_ref en unique ;
actor.tmdb_id en unique ;
movie_role(actor_id, movie_id) en unique ;
award_type.name en unique ;
idéalement award(actor_id, name, year) en unique ou via hash métier.

Code

dans FilmImporter, ActorSyncer et AwardImporter, remplacer les pré-checks fragiles par une logique find-or-create tolérante aux collisions ;
intercepter UniqueConstraintViolationException puis recharger l'entité créée par un autre worker ;
conserver les compteurs d'import cohérents même si une collision concurrente survient ;
couvrir explicitement le cas avec des tests de ré-entrée/idempotence.

Validation

tests d'import relancés deux fois sur le même CSV ;
test avec plusieurs messages batch sur les mêmes films ;
vérification qu'aucun doublon n'apparaît en base.

Impact

Fiabilité import : forte amélioration
Dette technique : réduite
Risque production : réduit significativement

## 1. Le souci L'import asynchrone découpe les films en batchs et peut traiter plusieurs messages en parallèle. Aujourd'hui, la déduplication repose surtout sur des vérifications applicatives (`findOneBy`, `count`) sans contraintes uniques alignées en base. Conséquences possibles : - création de doublons `movie`, `actor`, `movie_role`, `award_type`, `award` ; - collisions entre workers avec faux échecs d'import ; - comportement non déterministe si plusieurs workers traitent des films proches en même temps. ## 2. Proposition de solution Rendre le pipeline explicitement idempotent et robuste aux courses concurrentes. Pistes : - ajouter des contraintes uniques côté base sur les clés naturelles pertinentes ; - capturer les collisions d'unicité côté handlers/importers ; - faire en sorte qu'un retry Messenger n'aggrave jamais l'état des données ; - éviter les `count()` de présence comme seul garde-fou. ## 3. Proposition d'implémentation ### Schéma - `movie.ltbxd_ref` en unique ; - `actor.tmdb_id` en unique ; - `movie_role(actor_id, movie_id)` en unique ; - `award_type.name` en unique ; - idéalement `award(actor_id, name, year)` en unique ou via hash métier. ### Code - dans `FilmImporter`, `ActorSyncer` et `AwardImporter`, remplacer les pré-checks fragiles par une logique `find-or-create` tolérante aux collisions ; - intercepter `UniqueConstraintViolationException` puis recharger l'entité créée par un autre worker ; - conserver les compteurs d'import cohérents même si une collision concurrente survient ; - couvrir explicitement le cas avec des tests de ré-entrée/idempotence. ### Validation - tests d'import relancés deux fois sur le même CSV ; - test avec plusieurs messages batch sur les mêmes films ; - vérification qu'aucun doublon n'apparaît en base. ## Impact - Fiabilité import : forte amélioration - Dette technique : réduite - Risque production : réduit significativement