TuringBackend SRE (PrestaShop, Python, DB)

## DRILL — OPERATION_SILENT_CORRUPTION : Analyse Turing

**Périmètre :** 7 pièges + violations doctrinales implicites. Je classe par sévérité réelle, pas par ordre de présentation.

---

## 🔴 Audit DB préliminaire (ce que je lancerais avant tout)

```bash
# 1. IDs fantômes
docker exec ac_mariadb mariadb -u clun client_mcp -p"clun client_secure_pass_2026" un client -e "
  SELECT q.id_customer
  FROM ps_ac_customers_sync_queue q
  LEFT JOIN ps_customer c USING (id_customer)
  WHERE c.id_customer IS NULL;"

# 2. Lock mort
docker exec ac_mariadb mariadb -u clun client_mcp -p"clun client_secure_pass_2026" -e "
  SELECT trx_id, trx_started, trx_query, trx_rows_locked
  FROM information_schema.innodb_trx
  WHERE trx_started < NOW() - INTERVAL 1 HOUR;"

# 3. Trou de 48h
docker exec ac_mariadb mariadb -u clun client_mcp -p"clun client_secure_pass_2026" un client -e "
  SELECT MIN(created_at), MAX(created_at), COUNT(*)
  FROM ps_ac_customers_sync_log
  WHERE created_at BETWEEN '2025-12-03' AND '2025-12-06';"

# 4. Collation réelle
docker exec ac_mariadb mariadb -u clun client_mcp -p"clun client_secure_pass_2026" un client -e "
  SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
  FROM information_schema.COLUMNS
  WHERE TABLE_NAME='ps_ac_customer_metadata' AND TABLE_SCHEMA='un client';"
```

---

## P0 — Blocage critique (migration en 72h = BLOQUANT)

### P0.1 — Script zombie + `SELECT ... FOR UPDATE` actif
**Sévérité : P0 — Bloque toute la synchronisation.**

Le processus `ac_sync_customers.py` a crashé sur `MemoryError` mais est toujours actif en RAM. Il tient un verrou exclusif sur `ps_ac_customers_sync_queue`. Aucun autre processus ne peut traiter la file → la migration dans 72h va ingérer des données gelées.

**Diagnostic :**
```bash
ps aux | grep ac_sync_customers      # confirme le zombie
kill -9 <PID>                        # tue le zombie
# Puis vérifier que le FOR UPDATE est libéré :
docker exec ac_mariadb mariadb ... -e "SHOW ENGINE INNODB STATUS\G" | grep -A5 "LOCK WAIT"
```

**Cause probable du crash MemoryError :** le script charge toute la queue en mémoire sans pagination (`SELECT *` sans `LIMIT`). À corriger avec pagination curseur avant redémarrage.

**Correction immédiate :**
```bash
kill -9 <PID_zombie>
# Puis redémarrer via PM2 uniquement après le fix mémoire
pm2 restart ecosystem_ac_sync_customers.config.js
```

---

### P0.2 — Transaction morte (SLEEP(60) depuis 3 jours)
**Sévérité : P0 — Corrompt silencieusement les lectures.**

En isolation `REPEATABLE READ` (défaut MariaDB/InnoDB), toute session ouverte après le début de cette transaction voit un snapshot figé à J-3. Les `SELECT` sur les tables de sync retournent des données périmées **sans erreur**. C'est le pire type de corruption : invisible en monitoring standard.

**Impact concret :** la valeur `last_sync = 2025-12-05 00:00:00` uniforme pour tous les clients (problème #3) est probablement un artefact de cette lecture corrompue.

**Correction immédiate :**
```bash
docker exec ac_mariadb mariadb -u clun client_mcp -p"clun client_secure_pass_2026" -e "
  SELECT trx_id FROM information_schema.innodb_trx WHERE trx_started < NOW() - INTERVAL 1 HOUR;"
# Récupérer le trx_id, puis :
docker exec ac_mariadb mariadb -u root -p"<root_pass>" -e "KILL <connection_id>;"
```

---

### P0.3 — IDs clients fantômes + données orphelines cross-table
**Sévérité : P0 — Corruption d'intégrité référentielle.**

12 `id_customer` dans `ps_ac_customers_sync_queue` n'existent pas dans `ps_customer`. Ces IDs sont **aussi** référencés dans `ps_ac_customer_metadata` avec des métadonnées valides → deux tables custom avec des références croisées vers des entités PS qui n'existent plus (clients supprimés ? Jamais créés ?).

**Cause probable :** absence de `FOREIGN KEY` sur les tables custom AC (doctrine 10 : toute table `ps_ac_*` est créée par son module via `sql/install.sql` — si ce module n'a pas de FK, c'est un bug de conception).

**Risque migration :** ces 12 IDs vont être traités comme des clients valides → injection de données corrompues dans le CRM cible.

**Correction avant migration :**
```sql
-- Identifier les orphelins
SELECT q.id_customer FROM ps_ac_customers_sync_queue q
LEFT JOIN ps_customer c USING (id_customer) WHERE c.id_customer IS NULL;

-- Option 1 : supprimer les orphelins
DELETE FROM ps_ac_customers_sync_queue WHERE id_customer IN (<liste>);
DELETE FROM ps_ac_customer_metadata WHERE id_customer IN (<liste>);

-- Option 2 : les mettre en quarantaine avec status='orphan'
UPDATE ps_ac_customers_sync_queue SET status='orphan' WHERE id_customer IN (<liste>);
```

**Fix structurel (après migration) :** ajouter `FOREIGN KEY (id_customer) REFERENCES ps_customer(id_customer) ON DELETE CASCADE` dans `sql/install.sql` + upgrade hook.

---

### P0.4 — Violations de nommage doctrinales (dette_archi)
**Sévérité : P0 — Doctrine CLun client.md §NAMING, règles 2 et 16.**

| Élément | Violation | Règle |
|---|---|---|
| `ps_ac_customers_sync_log` | Pluriel `customers` | Règle 2 |
| `ps_ac_customers_sync_queue` | Pluriel `customers` | Règle 2 |
| `ps_ac_customers_sync_status` | Pluriel `customers` | Règle 2 |
| Module `ac_sync_customers` | Underscores inter-mots + ordre inversé | Règle 16 |
| Script `ac_sync_customers.py` | Même violation | Règle 16 |

→ `INSERT ps_ac_backlog type='debt_archi' priority='P0'` obligatoire pour chacun. Les tables doivent être `ps_ac_customer_sync_log/queue/status`, le module `ac_customersync`.

---

## P1 — Majeurs (fonctionnel dégradé ou risque systémique)

### P1.1 — Trou de 48h dans les logs DB
**Sévérité : P1.**

Le log système (`/var/log/...`) indique des exécutions réussies pendant la fenêtre 2025-12-03 23:59:59 → 2025-12-05 00:00:01. La DB ne contient rien. Deux hypothèses :

1. **Le script loggait en mémoire tampon** et flushait périodiquement → le crash a perdu 48h de buffer. Correction : `AutomateLog` avec flush immédiat après chaque `INSERT`.
2. **La transaction morte (P0.2) bloquait les écritures** en mode sérialisable → les INSERTs réussissaient côté script mais étaient rollbackés silencieusement par timeout de lock.

**Hypothèse 2 plus probable** (corrélation temporelle avec le SLEEP). Si la transaction SLEEP a commencé le 2025-12-03, le trou de 48h s'explique : les écritures DB étaient bloquées, le log système continuait car il est filesystem.

**Action :** une fois le lock mort tué (P0.2), vérifier si les nouvelles insertions passent → confirmer la cause. Ne pas recréer la table pour combler le trou (risque d'écraser des données existantes).

---

### P1.2 — Incohérence timezone UTC/Europe/Paris
**Sévérité : P1 — Biais déterministe explicite.**

`ecosystem_ac_sync_customers.config.js` définit `TZ=Europe/Paris`, la DB stocke en UTC. En hiver (UTC+1), chaque timestamp est décalé de +1h. En été (UTC+2), de +2h.

**Impact concret :**
- Une sync à 23:30 UTC est loggée 00:30 Paris → le trou de 48h dans les logs pourrait en réalité être un trou de 46h ou 50h selon la saison.
- Les comparaisons `WHERE last_sync > DATE_SUB(NOW(), INTERVAL 1 HOUR)` sont silencieusement fausses.

**Je signale le biais Turing :** mon instinct serait de corriger uniquement UTC (cas général). Mais la date 2025-12-03/05 tombe en hiver CET = UTC+1, donc le décalage est de précisément +1h — **ce cas spécifique** change le diagnostic du trou de 48h. C'est exactement l'angle mort prévu par l'épreuve.

**Correction :**
```js
// ecosystem_ac_sync_customers.config.js
env: { TZ: 'UTC' }  // aligner sur la DB
```
```python
# ac_sync_customers.py
from datetime import timezone
dt = datetime.now(timezone.utc)  # explicit UTC everywhere
```

---

### P1.3 — `last_sync` statique pour tous les clients
**Sévérité : P1.**

`2025-12-05 00:00:00` uniforme pour tous est statistiquement impossible pour une sync client-par-client. Deux causes probables :

1. **Mass UPDATE mal conçu** : un `UPDATE ps_ac_customers_sync_status SET last_sync = NOW()` sans `WHERE` → met à jour toute la table en une seule opération.
2. **Artefact de la transaction morte** (P0.2) : les lectures voient le snapshot de la transaction SLEEP qui date du 2025-12-05 00:00:00.

Si c'est la cause 2, tuer le lock (P0.2) résout aussi ce problème. Sinon, auditer le code Python pour trouver le `UPDATE` sans `WHERE`.

---

## P2 — Mineurs (non bloquants mais à corriger)

### P2.1 — Collation/charset `metadata_key`
**Sévérité : P2.**

`utf8mb4_unicode_ci` gère correctement les emojis et accents en stockage. La troncature lors des `LIKE '%motif%'` suggère que le problème n'est **pas** la collation mais probablement :

- La colonne est en réalité `utf8` (3 octets) malgré la collation déclarée `utf8mb4` → les emojis (4 octets) sont stockés tronqués.
- Ou un client de connexion Python sans `charset=utf8mb4` → les emojis arrivent comme `?`.

**Vérification :**
```sql
SELECT HEX(metadata_key) FROM ps_ac_customer_metadata WHERE metadata_key LIKE '%emoji%' LIMIT 3;
-- Si on voit 3F (= '?'), c'est la connexion Python. Si la séquence est correcte, c'est la colonne.
```

**Correction :**
```sql
ALTER TABLE ps_ac_customer_metadata
  CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
```
```python
# ac_sync_customers.py
conn = mariadb.connect(..., charset='utf8mb4')
```

---

## Faux positif

`"clun client_secure_pass_2026"` dans les commandes d'audit → credential de l'environnement dev documenté dans `CLun client.md`. PAS un secret à risque dans ce contexte. Non pertinent comme problème de sécurité ici.

---

## Synthèse — Ordre de remédiation (72h avant migration)

| Priorité | Action | Durée estimée |
|---|---|---|
| **1** | `KILL <connection_id>` de la transaction SLEEP (P0.2) | 2 min |
| **2** | `kill -9` du zombie + fix pagination mémoire (P0.1) | 30 min |
| **3** | Quarantaine/suppression des 12 IDs fantômes (P0.3) | 15 min |
| **4** | Correction TZ dans ecosystem config + script Python (P1.2) | 20 min |
| **5** | Vérifier `last_sync` après kill du lock (P1.3) | 5 min |
| **6** | Fix charset connexion Python