AD-DEV Error Monitoring

Capture et suivi des erreurs des applications construites sur le framework AD-DEV. Les erreurs identiques sont regroupées par empreinte (type, message, route, début de la trace, source — identifiants et nombres masqués) : un groupe (errmon_event) porte le dernier instantané, le nombre d'occurrences et un statut de tri (new, investigating, resolved, ignored) ; chaque occurrence (errmon_occurrence) garde l'historique.

Le package a trois entrées :

L'assembly .NET ADDEV.Framework.ErrorMonitoring (ErrorMonitoring.csproj) reste disponible pour les backends C# historiques.

Backend

server.setConfigOverrides({
  errorMonitoring: {
    // Ressource de permission des handlers de consultation
    // (`read` : liste et détail, `update` : statut). `null` : admins.
    permissionResource: 'errors',
    appVersion: '1.2.0',
  },
});
await server.use(authModule);
await server.use(errorMonitoringModule);
await server.migrate();

Le module publie :

• POST /api/error-monitoring/collect — ingestion publique, limitée par IP (collectRateLimit). L'utilisateur est lu dans le cookie de session, jamais dans le corps de la requête.
• errorMonitoring.events.list (groupes les plus récents d'un environnement + chiffres : groupes par statut, occurrences sur 24 h, utilisateurs touchés par les erreurs ouvertes), errorMonitoring.events.get (trace, contexte, occurrences récentes) et errorMonitoring.events.setStatus.
• La capture des requêtes WS et des appels d'outils MCP qui échouent de façon inattendue (codes handler_failed / invalid_response, via l'événement request.completed), source backend.ws / backend.mcp.
• services.errorMonitoring.captureException(err, { source }) pour le reste du code backend (tâches planifiées, webhooks…).
• Les événements errorMonitoring.captured et errorMonitoring.statusChanged.

Données personnelles et conservation :

• Les tables errmon_* suivent le modèle de base (id, created_at, updated_at, deleted_at) : aucune ligne n'est supprimée en SQL, toute lecture ignore les lignes soft-deleted.
• La query string et le fragment de url / route sont retirés à l'envoi (navigateur) et à la réception (backend) : ils peuvent porter des jetons.
• Le message, la trace et le contexte sont nettoyés aux deux mêmes endroits : paramètres SQL d'une erreur Drizzle (tout ce qui suit params:), e-mails ([email]), valeurs token= / code= / key= / secret= / password=, suites hexadécimales ou base64url de 32 caractères ou plus ([redacted]). Le contexte est limité à 16 000 caractères.
• La date envoyée par le client n'est gardée que si elle tombe entre maintenant − 24 h et maintenant + 5 min ; sinon, l'heure de réception.
• retentionDays (défaut 0 : conservation sans limite). Une app soumise au RGPD doit fixer cette valeur (par exemple 90). Une tâche quotidienne (errorMonitoring.retention) soft-delete alors, par lots, les occurrences plus anciennes et les groupes dont la dernière occurrence l'est, en effaçant l'utilisateur (id, e-mail, nom) et le texte libre (message remplacé par [purged], trace, contexte et URL vidés). Une erreur qui revient ensuite ouvre un nouveau groupe.
• services.errorMonitoring.anonymizeUser(userId) (demande d'effacement RGPD) vide l'utilisateur (id, e-mail, nom) de ses occurrences et des groupes dont il est le dernier utilisateur, sans rien soft-delete : les groupes restent visibles avec les occurrences des autres utilisateurs.
• allowedOrigin (défaut null : aucun contrôle) : l'origine de l'app. Une fois renseignée, la route de collecte refuse Sec-Fetch-Site: cross-site et toute autre Origin.
• La route de collecte n'accepte qu'un corps application/json de 32 Kio au plus ; la limite de débit regroupe les adresses IPv6 par /64.

Environnement enregistré, par ordre de priorité : celui envoyé par le client, errorMonitoring.environment, CI_ENVIRONMENT_NAME, DEPLOY_ENV, puis unknown.

Mise à jour depuis 5.12

• server.migrate() applique la migration 0002_soft_delete (colonnes de base, index unique de l'empreinte limité aux groupes non supprimés).
• Types : ErrorMonitoringEventRow et ErrorMonitoringOccurrenceRow gagnent des champs obligatoires (createdAt, updatedAt, deletedAt, et notDeleted pour les groupes). Un code qui construit ces objets à la main (store personnalisé, tests) doit les ajouter.
• Un store personnalisé peut implémenter purgeOlderThan(cutoff, limit) et anonymizeUser(userId) ; sans elles, la conservation et l'effacement journalisent errorMonitoring.retention.unsupported / errorMonitoring.anonymize.unsupported et ne font rien.
• La route de collecte lit son corps elle-même : elle refuse désormais un corps qui n'est pas application/json (415) ou dépasse 32 Kio (413).
• Le comportement par défaut ne change pas pour la conservation (retentionDays: 0) ni pour l'origine (allowedOrigin: null).

Frontend

<ErrorMonitoringProvider>
  <ErrorMonitoringBoundary fallback={<CrashPage />}>
    <App />
  </ErrorMonitoringBoundary>
</ErrorMonitoringProvider>

Le provider écoute error et unhandledrejection sur window (sources frontend.react.window / .promise), la boundary les erreurs de rendu (frontend.react.boundary, avec la pile des composants). Les rapports identiques à moins de 5 s d'intervalle ne partent qu'une fois.

Consultation : useErrorEvents(environment), useErrorEvent(id), useSetErrorEventStatus() (sur @addev-be/node-frontend).