🐛 [BUG] - Race condition sur les secrets Vault lors du provisionnement concurrent (symptôme : `SONAR_PASSWORD = 'not initialized'`) — server-nestjs

[KepoParis]

Description

Sur le nouveau serveur server-nestjs, il arrive de façon intermittente que le secret Vault SONAR d'un projet contienne SONAR_PASSWORD: 'not initialized' au lieu du vrai mot de passe. Avec l'ancien plugin plugins/sonarqube, ce problème n'apparaît jamais.

La valeur 'not initialized' n'est pas un bug en soi : c'est un repli légitime lorsque l'utilisateur SonarQube existe mais que son secret Vault a réellement disparu (SonarQube ne permet pas de relire un mot de passe). Le problème est que, dans le nouveau serveur, cette valeur est écrite alors qu'un mot de passe valide vient d'être créé — il y a donc perte de données.

Cause : une race condition, pas un bug de chemin. La logique et le chemin Vault (<PROJECTS_ROOT_DIR>/<slug>/SONAR) sont identiques entre l'ancien plugin et le nouveau serveur. La différence est la concurrence :

• l'événement project.upsert est émis depuis de nombreux endroits (project, project-roles, environment, deployment, project-hooks…) ;
• certaines émissions se font sans await (fire-and-forget, ex. deployment.service.ts:98, environment.service.ts:76), donc deux réconciliations du même projet peuvent se chevaucher ;
• rien ne sérialise le traitement par projet (emitAsync n'a aucun verrou par projet).

ensureUser effectue une séquence lecture → vérification → écriture non atomique sur le secret. Sur un projet fraîchement créé, deux exécutions concurrentes se déroulent ainsi :

Étape	Run A	Run B
1	lit le secret → 404	lit le secret → 404
2	utilisateur absent	—
3	crée l'utilisateur + écrit le vrai mot de passe	—
4	—	utilisateur désormais trouvé (créé par A), lecture initiale = 404 → branche else
5	—	écrit SONAR_PASSWORD: 'not initialized' ❌ écrase le mot de passe de A

Le résultat dépend de l'ordre d'exécution → comportement non déterministe (« parfois »).

⚠️ Portée plus large. SonarQube n'est que le symptôme le plus visible. Le vrai sujet est l'absence de sérialisation par projet dans le nouveau modèle de gestion des plugins : tout plugin faisant un cycle lecture-modification-écriture sur un secret Vault (ou toute autre ressource) est exposé au même type de race lors de provisionnements concurrents. À traiter idéalement de façon transverse.

Etapes de reproduction

# Reproduction déterministe (illustre la branche de code fautive)
1. Provisionner un projet (secret SONAR créé avec un vrai mot de passe)
2. Supprimer manuellement tous les secrets Vault du projet
   (l'utilisateur SonarQube, lui, n'est PAS supprimé)
3. Reprovisionner le projet
4. Constater SONAR_PASSWORD = 'not initialized' :
   le secret est lu en 404, mais l'utilisateur existe déjà → branche de repli

# Note : cette reproduction déclenche la même branche sur l'ancien plugin.
# Ce qui est propre au nouveau serveur, c'est d'atteindre cette branche
# SANS suppression manuelle, via une race condition (perte de données) :

# Reproduction de la régression (intermittente)
5. Déclencher plusieurs provisionnements rapprochés d'un même projet neuf
   (création du projet + ajout d'un rôle / environnement / déploiement quasi simultanés)
6. Laisser les événements project.upsert se chevaucher
7. Constater par intermittence SONAR_PASSWORD = 'not initialized'
   alors qu'un vrai mot de passe venait d'être écrit

Piste technique (où se trouve l'erreur & suggestions)

Symptôme localisé dans apps/server-nestjs/src/modules/sonarqube/sonarqube.service.ts, méthode ensureUser (lecture ligne 201, branche else ligne 213-216, écriture ligne 220).

Suggestions, du plus ciblé au plus transverse :

1. Écriture non destructrice : ne jamais écraser un SONAR_PASSWORD valide existant. Relire le secret juste avant d'écrire, ou n'écrire 'not initialized' qu'après confirmation que le secret est réellement absent (idéalement via un check-and-set / CAS Vault).
2. Sérialisation par projet : introduire un verrou/mutex par slug autour de la réconciliation d'un projet, afin que deux project.upsert du même projet ne se chevauchent pas.
3. Transverse (recommandé) : traiter la sérialisation par projet au niveau du bus d'événements / gestionnaire de plugins (app-events.service.ts), plutôt que plugin par plugin — cela protège l'ensemble des plugins (GitLab, Nexus, Registry, Vault…) contre la même classe de bug. Corollaire : les émissions project.upsert en fire-and-forget (deployment.service.ts:98, environment.service.ts:76) devraient passer par ce mécanisme sérialisé.

Version de la console impactée

v9.23.0