Aller au contenu

feed-sync

Status: TARGET

Rôle

Cette page décrit la capacité cible d’un point d’entrée CLI dédié à la synchronisation d’un feed marchand.

Elle ne constitue pas la preuve qu’une commande littérale feed-sync est actuellement enregistrée dans WP-CLI.

Avant toute utilisation, vérifier les commandes réellement disponibles dans le Runtime :

docker compose exec platform-worker wp --allow-root --path=/var/www/html help ccx

ou inspecter l’arbre JSON complet de :

docker compose exec platform-worker wp --allow-root --path=/var/www/html cli cmd-dump --format=json

avec un parseur JSON.

Pourquoi cette capacité existe

Une synchronisation de feed est une opération d’écriture et d’orchestration. Elle peut déclencher :

  • téléchargement ou lecture d’une source marchande ;
  • ingestion ;
  • Stage ;
  • normalisation ;
  • enrichissement ;
  • résolution ;
  • construction ou reconstruction de projections ;
  • mise à jour d’états techniques de run.

Elle doit donc rester séparée des commandes d’audit, de dump et de simulation.

Frontière d’architecture attendue

WP-CLI adapter
    ↓
façade applicative / action service
    ↓
Runtime / Pipeline
    ↓
Write Services et Infrastructure

L’adapter CLI ne doit pas contenir lui-même :

  • le Pipeline ;
  • du SQL métier ;
  • des règles de résolution ;
  • des règles propres à une verticale ;
  • des écritures directes dans les projections.

Il parse les arguments, valide le contexte, délègue puis traduit le résultat.

Activation des feeds

Une commande de synchronisation ne doit pas déduire l’activation d’un marchand à partir de sa seule présence dans le registry.

L’autorité d’activation reste :

  • CCX_ACTIVE_FEEDS ;
  • ccx_feed_runtime_active_feeds().

ccx_feeds_registry() peut contenir des feeds ACTIVE et PREPARED.

Un feed PREPARED est inspectable et préparé techniquement, mais n’est pas actif pour autant.

Entrées minimales

Une implémentation de synchronisation doit rendre explicites au minimum :

  • le feed ou marchand ciblé ;
  • le mode d’exécution ;
  • le run concerné lorsqu’il existe ;
  • les limites ou batchs éventuels ;
  • les options de reprise ;
  • les paramètres susceptibles de modifier le comportement.

Sortie attendue

Le résultat doit permettre de distinguer :

  • éléments lus ;
  • éléments importés ;
  • éléments traités ;
  • éléments ignorés ;
  • erreurs ;
  • écritures réellement effectuées ;
  • statut final ;
  • identifiant du run ou batch ;
  • raisons principales d’échec ou d’ignorance.

Les compteurs doivent être réconciliables.

Reprise et idempotence

Une interruption ne doit pas rendre le run opaque.

La capacité doit préciser :

  • comment identifier le dernier état valide ;
  • comment reprendre sans dupliquer les effets ;
  • comment distinguer une ligne déjà conforme d’une ligne réellement modifiée ;
  • comment vérifier le résultat après reprise.

Ce qu’il ne faut jamais faire

Ne pas :

  • lancer une synchronisation pour “voir ce que ça fait” ;
  • assimiler PREPARED à ACTIVE ;
  • activer un marchand en modifiant seulement le registry ;
  • corriger des données en production par SQL direct parce qu’une sync a échoué ;
  • présenter une simulation comme une synchronisation réelle ;
  • reconstruire manuellement une projection sans passer par les services dédiés.

Workflow opérateur sûr

1. vérifier l’environnement
2. vérifier que le feed est réellement actif
3. capturer l’état et les métriques de départ
4. vérifier la commande réellement disponible
5. lancer la synchronisation avec un périmètre borné
6. observer les compteurs et erreurs
7. vérifier les projections et états techniques concernés
8. comparer avec la baseline

Si la synchronisation révèle une anomalie métier, revenir ensuite vers les Read Services et audits plutôt que corriger directement la base.

Voir aussi