[NestJS] Migrer le plugin observability depuis Fastify vers server-nestjs #2418

Activity

1. shikanime

   added

   tech

   refactorRefactor codeRefactor code

   on Aug 5, 2026
2. shikanime

   changed the title [-][refactor] Migrer le plugin observability vers le module NestJS[/-] [+][NestJS] Migrer le plugin observability depuis Fastify vers server-nestjs[/+] on Aug 5, 2026
3. shikanime

   added

   technical debtRésoud de la dette techniqueRésoud de la dette technique

   on Aug 5, 2026
4. shikanime

   self-assigned this

   on Aug 5, 2026
5. shikanime

   added the

   Task

   issue type on Aug 5, 2026
6. shikanime

   added this to the 9.24.0 milestone on Aug 5, 2026
7. shikanime

   added a parent issue on Aug 5, 2026

   • [NestJS] Modularisation de server #1889
8. StephaneTrebel

   marked this as blocking on Aug 6, 2026

   • 💡 [REQUEST] - Déplacer les values observability #1649
9. shikanime

   closed this as completedon Aug 7, 2026
10. shikanime commented on Sep 7, 2026

    

    shikanime

    on Sep 7, 2026

    MemberAuthor

    More actions

    Investigation: users lost Grafana access after the server-nestjs observability migration

    Root cause (proven): getListPerms in apps/server-nestjs/src/modules/observability/observability.utils.ts assigns every project user to exactly one Grafana bucket pair — prod if any prod environment exists, hors-prod otherwise. The legacy plugin (console-plugin-observability src/function.ts) bucketed per-stage: the Fastify hook wrapper (apps/server/src/utils/hook-wrapper.ts transformToHookProject) attached the same permission list to every environment, so users landed in both the prod and hors-prod Keycloak group pairs.

    Because ObservabilityService.reconcileGroupMembership is a diff-and-remove sync, on the first project.upsert under server-nestjs every member of the group pair opposite to the chosen bucket is removed from Keycloak — and Grafana maps org roles from those groups. Loss of access follows deterministically.

    Evidence (repro): apps/server-nestjs/src/modules/observability/zz-investigate-repro.spec.ts

    pnpm vitest run src/modules/observability/zz-investigate-repro.spec.ts
    ✓ legacy contract: owner/member expected in BOTH buckets when both stages exist
    × 2 failed — perms['hors-prod'] is [] when a prod env exists (and vice versa)
    

    The existing spec (observability.utils.spec.ts) asserts the new semantics as intended behavior (assigns to prod bucket when a prod environment exists), so this is a behavioral regression against the legacy contract, not an accidental typo — the spec codified the wrong contract.

    Secondary deltas vs legacy worth noting:

    1. Legacy ensureKeycloakGroups resolved the root group via keycloakApi.getProjectGroupPath(); NestJS uses generateKeycloakRootGroupPath(project) = /${slug} — equivalent today, but the legacy path came from the Keycloak plugin's canonical source.
    2. NestJS adds 404-tolerant add/remove (users without a Keycloak account are skipped with a warning) — an improvement; keep it.

    Proposed solution (single change at the source): in getListPerms (observability.utils.ts), restore per-stage bucketing: for each user compute (ro, rw) once, then add to prod if any prod-stage environment exists and add to hors-prod if any non-prod environment exists — i.e. mirror the legacy semantics where both pairs receive the full permission roster. Update the three assertions in observability.utils.spec.ts that codified the single-bucket contract.

    Sketch:

    for (const userId of projectUserIds) {
      const { ro, rw } = resolveUserPerms(project, rolesById, userId)
      const hasProd = project.environments.some(e => isProdStage(e.stage))
      const hasHprod = project.environments.some(e => !isProdStage(e.stage))
      if (hasProd) {
        if (rw && !perms.prod.edit.includes(userId)) perms.prod.edit.push(userId)
        if (ro && !perms.prod.view.includes(userId)) perms.prod.view.push(userId)
      }
      if (hasHprod) {
        if (rw && !perms['hors-prod'].edit.includes(userId)) perms['hors-prod'].edit.push(userId)
        if (ro && !perms['hors-prod'].view.includes(userId)) perms['hors-prod'].view.push(userId)
      }
    }

    Regression test: keep zz-investigate-repro.spec.ts assertions (both buckets populated when both stages exist), promoted into observability.utils.spec.ts; plus an end-to-end guard in observability.service.spec.ts: given existing Keycloak members in both pairs and a project with both stages, reconcileGroupMembership removes nobody.

    Remediation note for affected instances: removing users was destructive — after deploying the fix, a project.upsert replay per affected project re-adds the removed memberships (re-add is idempotent; the sync restores desired state).

    Handing off to sks-dev-workflow / sks-pr for the actual change.
11. shikanime

    linked a pull request that will close this issuefeat(server-nestjs): migrate observability plugin to NestJS module #2419on Oct 8, 2026