🐛 [BUG] - gitlab-client : createGroupRepo et commit concurrents sans tolérance au conflit (Observability + ArgoCD)

[shikanime]

Description

Deux trous d'idempotence résident dans gitlab-client.service.ts, partagés par les modules Observability et ArgoCD.

1. createGroupRepo sans tolérance au conflit (gitlab-client.service.ts:297-307) — appelé par getOrCreateValuesRepo (observability-client.service.ts:38) sur chaque upsert projet (observability.service.ts:129) et chaque suppression (:147). C'est un Projects.create brut sans traitement du has already been taken. Deux synchronisations concurrentes qui voient toutes deux le dépôt absent appellent toutes deux createGroupRepo ; la seconde lève le 409 GitLab. Pattern identique à celui déjà corrigé pour les sous-groupes keycloak (keycloak-client.service.ts:212-220) et les dépôts système (gitlab-client.service.ts:274-279, qui relit sur has already been taken).

2. Course lecture-écriture sur le commit (maybeCreateCommit, gitlab-client.service.ts:321 + generateCreateOrUpdateAction :336-348) — l'action lit le fichier puis un Commits.create séparé écrit (:332). Deux syncs qui se chevauchent peuvent voir le fichier absent, émettre toutes deux action: 'create', et la seconde frappe le « already exists » GitLab avec 400 sans tolérance → la sync échoue. Même schéma pour les delete concurrents.

Etapes de reproduction

1. Déclencher une synchronisation concurrente du même projet.
2. Pour le cas 1 : deux runs voient le dépôt de valeurs absent et l'un des createGroupRepo lève has already been taken.
3. Pour le cas 2 : deux runs voient le fichier absent, les deux émettent action: 'create', le second Commits.create lève un 400.

Version de la console impactée

server-nestjs (gitlab-client — modules Observability et ArgoCD)

Définition du fini

• createGroupRepo tolère has already been taken et relit le dépôt existant (idiome gitlab-client.service.ts:274-279)
• Le commit concurrent tolère le conflit de création et réconcilie (relit le fichier / no-op si déjà présent)
• Les tests liés à ce correctif ont été ajoutés

Issues liees

Relie a #2087 : migration des plugins vers une approche declarative (moteur Alchemy.run), dont cette idempotence est un prerequis.