_Assistant_Lead_Tech/90_debug_et_postmortem.md

Debug & post-mortems

Ce fichier sert à capitaliser sur les problèmes rencontrés.

À documenter

• bug pénible
• mauvaise compréhension
• fausse hypothèse
• solution finale

Objectif

Ne plus jamais perdre du temps sur le même problème.

---

Post‑mortems

SQL Server qui crash dans un conteneur LXC Proxmox

Contexte

NUC personnel sous Proxmox avec plusieurs services en conteneurs LXC. Un conteneur SQL Server (Microsoft SQL Server Linux) ne démarrait plus.

Symptômes

• sqlcmd impossible → timeout
• service mssql-server en boucle de restart
• logs contenant :

Operation not permitted
chmod: changing permissions of '/var/opt/mssql/log/...'

• crash + génération de core dump

Cause probable

SQL Server utilise certaines opérations système qui sont mal supportées dans les conteneurs LXC (permissions, filesystem, capabilities).

Dans un environnement Proxmox LXC, cela peut casser après :

• une mise à jour
• un changement de permissions
• un changement de configuration du conteneur

Conclusion

SQL Server n'est pas un bon candidat pour un conteneur LXC Proxmox.

Décision architecturale

Pour un homelab ou un petit serveur :

• éviter SQL Server en LXC
• préférer :
  • PostgreSQL
  • MariaDB / MySQL

Si SQL Server est nécessaire :

• utiliser une VM complète plutôt qu'un conteneur.

Règle à retenir

Éviter les bases lourdes nécessitant des capabilities système avancées dans des conteneurs LXC.

---

Suppression silencieuse due à deux éditions concurrentes sur le même fichier

Contexte

Un même fichier a été modifié par deux mécanismes proches dans le temps : édition en cours d’agent et passe outillée/linter/formatteur.

Symptômes

• bloc de code disparu sans erreur explicite
• diff final incohérent avec l’intention de modification
• impression de “régression fantôme” après une édition pourtant correcte

Cause probable

Deux processus ont réécrit le même fichier sans coordination, le second écrasant silencieusement une partie du travail du premier.

Correctif / règle à retenir

• éviter deux passes d’écriture concurrentes sur le même fichier
• relire le diff immédiatement après toute passe automatique
• privilégier une séquence stricte : édition, puis lint/format, puis vérification

---

tsx + NestJS : injection par type cassée silencieusement

Contexte

Projet app-alexandrie, Epic 3, le 10-03-2026. Le backend NestJS tournait avec tsx watch dans un contexte ESM (module: nodenext), notamment pour rester compatible avec Prisma v7.

Symptômes

• TypeError: Cannot read properties of undefined (reading 'get') dans le constructeur d’un service
• ConfigService injecté par type mais undefined au runtime
• @Injectable() et ConfigModule correctement configurés, sans erreur de compilation

Cause probable

tsx repose sur esbuild pour transpiler TypeScript. Dans ce contexte, emitDecoratorMetadata est ignoré même s’il est activé dans tsconfig.json. NestJS ne peut donc plus résoudre correctement certaines injections par type, notamment constructor(private readonly config: ConfigService).

Correctif / règle à retenir

• ne pas supposer que emitDecoratorMetadata fonctionne avec tsx
• dans ce contexte, éviter l’injection par type de ConfigService pour les services d’infra
• lire explicitement les variables via process.env, après chargement amont de ConfigModule.forRoot()

Exemple :

// AVANT
constructor(private readonly config: ConfigService) {
  const host = this.config.get('REDIS_HOST');
}

// APRES
constructor() {
  const host = process.env['REDIS_HOST'] ?? 'localhost';
}

Alternative écartée

nest start --watch a été testé mais a introduit des conflits ESM/CJS dans ce contexte (exports is not defined).