🐛 [BUG] server-nestjs: projectMember.upsert/delete events have no consumer (GitLab member sync dead)

[shikanime]

Contexte / Context

La migration apps/server → apps/server-nestjs mappe les syncs de plugins via des événements :

• apps/server (legacy) : fire hook.projectMember.upsert(projectId, userId) / hook.projectMember.delete(projectId, userId) depuis resources/project-member/business.ts:52,61,69.
• apps/server-nestjs : émet via AppEventsService.emitProjectMemberEvent(...) → EventEmitter2 → consommateurs @OnEvent.

Côté legacy, le hook est consommé par le plugin gitlab : plugins/gitlab/src/index.ts:86-95 enregistre upsertProjectMember (étapes pre/main) et deleteProjectMember (post) — synchronisation des membres du projet côté GitLab.

Problème / Problem

Dans apps/server-nestjs, project-members.service.ts:62,127,152 émet projectMember.upsert / projectMember.delete, mais aucun module n'écoute ces événements :

grep -rln "OnEvent" apps/server-nestjs/src --include="*.ts" | xargs grep -l "projectMember"
# (aucun résultat)

Conséquence : l'ajout, la mise à jour en lot ou la suppression d'un membre projet ne se répercute plus sur GitLab (invitations/permissions du groupe miroir). Le portage est silencieux — pas d'erreur, juste une dérive d'état.

Issues liées

• Campagne de tests : 🧪 Campaign: full console test coverage vs server-nestjs migration (unit + e2e + Playwright) #2574
• Blockers de bascule voisins : 🐛 [BUG] server-nestjs: zone.upsert/zone.delete listeners have no emitter (AppEventsService missing emitZoneEvent) — cutover blocker #2575 (zone.*), 🐛 [BUG] server-nestjs: cluster.upsert/cluster.delete ont aucun module ni émetteur — cutover blocker #2576 (cluster), 🐛 [BUG] server-nestjs: harbor — aucun module (project mirror via harborsyncplugin non migré) — cutover blocker #2577 (harbor)

Définition du fini

• Le choix de conception est tranché et documenté dans cette issue (consommateurs @OnEvent dans un module gitlab nestjs vs arrêt des émissions)
• Le comportement cible couvre les trois sites d'émission (project-members.service.ts:62,127,152)
• Les specs verrouillant ce comportement sont ajoutées sous apps/server-nestjs
• La parité avec le contrat legacy gitlab (pre/main/post) est vérifiée

[shikanime]

Constat de raffinage (parité legacy ↔ nestjs vérifiée dans le code) :

• Legacy : hook.projectMember.upsert/delete → plugin gitlab (plugins/gitlab/src/index.ts:86-95), handlers upsertProjectMember/deleteProjectMember (plugins/gitlab/src/functions.ts:316,342) qui synchronisent les membres du groupe GitLab.
• Nestjs : project-members.service.ts:62,127,152 émet projectMember.upsert/delete, zéro consommateur @OnEvent (vérifié par grep sur tout apps/server-nestjs/src).
• Atténuation existante : GitlabService réconcilie les membres via @OnEvent('project.upsert') → ensureProjectGroupMembers (gitlab.service.ts:141-156) et un cron. La dérive d'un ajout/suppression unitaire est donc corrigée au prochain project.upsert ou tick cron — pas immédiatement.
• Question ouverte (choix de conception) : brancher un consommateur granulaire @OnEvent('projectMember.*') sur le chemin existant, où compter sur la réconciliation project-level + cron et débrancher les émissions mortes ? Le corps reste le lieu de la décision.