[shikanime]

Issues liées

Refs #2590

---

Quel est le comportement actuel ?

project-members.service.ts émet projectMember.upsert / projectMember.delete via AppEventsService, mais aucun consommateur @OnEvent('projectMember.*') n'existe dans server-nestjs : les événements sont émis sans effet et la synchronisation des membres du groupe GitLab ne se fait plus sur les routes déjà basculées (/api/v1/projects).

Quel est le nouveau comportement ?

Le module gitlab consomme les deux événements :

• projectMember.upsert → re-synchronisation complète des membres du groupe GitLab du projet (réutilise ensureProjectGroupMembers), en parité avec l'étape main du hook legacy upsertProjectMember ;
• projectMember.delete → suppression ciblée du membre du groupe (résolution email → utilisateur GitLab, puis removeGroupMember) ; utilisateur absent de GitLab = OK, en parité avec l'étape post du hook legacy deleteProjectMember ; groupe absent = OK sans création (voir la différence assumée ci-dessous).

Différence assumée avec le legacy : le hook deleteProjectMember appelait gitlabApi.removeGroupMember, qui passait par getOrCreateProjectGroup et créait donc le groupe GitLab en effet de bord d'une suppression. Le consommateur NestJS ne crée plus le groupe : groupe absent ⇒ OK sans création, une suppression ne doit pas avoir d'effet créateur. C'est cette divergence (et non une parité stricte) qui est couverte par le test « should tolerate a missing GitLab group ».

Les trois sites d'émission restent inchangés. Les résultats passent par capturePluginResult (échec → KO tracé dans le journal admin), comme les consommateurs project.* existants.

Cette PR introduit-elle un breaking change ?

Non.

Autres informations

• Specs ajoutées : réconciliation upsert (membre + owner), KO si projet absent, suppression du membre, tolérances delete (utilisateur absent, groupe absent).
• La PR test(server-nestjs): verrouille la parité d'émission projectMember + garde anti-consommateur fantôme #2579 (garde anti-consommateur fantôme) a été fermée sans fusion : il n'y a donc aucune assertion négative à retirer une fois cette PR fusionnée.

[github-actions]

🤖 Hey !

A preview of the application is available at : https://console-pr-2721.dso.cpin-hp.numerique-interieur.fr

Please be patient, deployment may take a few minutes.

[shikanime]

Verdict : Commentaire

Le pont projectMember est propre : l'émission part après commit de la transaction (project-members.service.ts émet hors du $transaction), le handler relit l'état en base — donc idempotent au replay — et la suppression tolère un utilisateur GitLab ou un groupe absents sans faire échouer l'événement. Pas de finding.

[StephaneTrebel]

Le pont projectMember couvre les deux événements et reste idempotent pour les suppressions rejouées. La branche est à 59 commits de main : rebase nécessaire, suivi d’une relance des contrôles, avant approbation.

[StephaneTrebel]

Relecture de la tête actuelle : les consommateurs projectMember.upsert/delete utilisent capturePluginResult et les cas d’absence GitLab sont couverts. La PR étant en brouillon, aucun verdict formel n’est publié.

[shikanime]

Revue conventions + structure : titre et commits conformes (adresse -open + co-authored-by Automata), brouillon cohérent avec la dépendance à #2579. Le consommateur upsert réutilise ensureProjectGroupMembers (pas de duplication) et la suppression ne crée rien, avec la divergence assumée et testée vis-à-vis du legacy. Un point important en inline : la résolution email → utilisateur GitLab passe par une recherche floue sans vérification d'égalité exacte, sur un chemin destructif. Note : le garde suspended est absent de tout server-nestjs à ce head (fonctionnalité revertée, cf. 097376a3) — cohérent avec les handlers project.* existants, à réintroduire le moment venu. Le retrait des assertions négatives de #2579 après fusion est bien tracé dans la description.

[shikanime]

Corrigé sur le head 3b291cf4 — gitlab-client.service.ts:420 ne prend plus le premier résultat de la recherche floue :

   async getUserByEmail(email: string) {
-    const users = await this.client.Users.all({ search: email, orderBy: 'username' })
-    if (users.length === 0) return undefined
-    return users[0] as UserSchema
+    // Fuzzy search matches username and display name too; only an exact
+    // email hit is safe on destructive paths (member removal).
+    const users = await this.client.Users.all({ search: email, orderBy: 'username' })
+    return users.find(user => user.email === email) as UserSchema | undefined
   }

createUser passe déjà par ce chemin pour sa réconciliation 409 : une absence de match exact renvoie undefined et la création 409 ressort — comportement inchangé. Bonus sur ce head : getOrCreateProjectSubGroup cassait nest build (TS2339, la méthode s'appelle ensureProjectSubGroup) et le spec moquait upsertUser disparu — les deux réparés, 116/116 locaux.

[shikanime]

Branche rebasée sur main@origin courant (8739c158), conflits résolus et contrôles relancés localement — la branche passe de 3 commits derrière une base périmée à 3 commits directement sur main :

• Rebase fix/project-member-gitlab-sync sur 8739c158 (main courant) ; nouvelle tête : 0618b789 (état distant vérifié par git ls-remote).
• Conflits résolus en union : les handlers zone.upsert/zone.delete de main cohabitent avec les consommateurs projectMember.* ; la ligne d'import fusionne ProjectMemberEventPayload + ZoneEventPayload ; les renommages de main (ensureProjectSubGroup, ensureUser) sont repris dans les chemins de la PR.
• Portée inchangée : jj diff -r main@origin..@ --stat = les 3 fichiers d'origine (gitlab.service.ts, gitlab.service.spec.ts, gitlab-client.service.ts).
• Contrôles locaux sur la tête : nest build OK (0 erreur), vitest run src/modules/gitlab/gitlab.service.spec.ts → 39/39 passés, eslint ciblé OK (une collation perfectionist corrigée par eslint --fix, repliée dans le commit).
• La PR test(server-nestjs): verrouille la parité d'émission projectMember + garde anti-consommateur fantôme #2579 (garde anti-consommateur fantôme) ayant été fermée sans fusion, le paragraphe correspondant de la description a été corrigé : aucune assertion négative à retirer.

[cloud-pi-native-sonarqube]

Quality Gate passed

Issues

• 0 New Issues
• 0 Fixed Issues
• 0 Accepted Issues

Measures

• 0 Security Hotspots
• 0.00% Coverage (53.70% Estimated after merge)
• 0.00% Duplicated Code (3.70% Estimated after merge)

Project ID: cloud-pi-native_console_AYsa46O31ebDtzs-pYyZ

View in SonarQube

done

[StephaneTrebel]

No findings. Les deux consommateurs couvrent les trois sites d’émission après transaction et remontent leurs résultats via capturePluginResult, conformément au choix documenté dans #2590 et à la divergence assumée pour un groupe absent. Les 150 tests existants et quatre sondes supplémentaires passent, dont deux reproduisent le défaut de recherche floue avec l’ancienne méthode ; lint ciblé et CI verts, SonarQube sans nouvelle issue et cinq fils déjà résolus.

Test Files  8 passed (8)
     Tests  154 passed (154)