Description
Les erreurs ne sont pas formatées de la même façon selon le serveur qui répond :
- Legacy (
apps/server), erreurs gérées (ErrorResType) : { "message": "..." }
- Legacy, erreurs non gérées (
setErrorHandler dans app.ts) : { "status": 500, "error": "<message>", "stack": "..." }
- NestJS (
apps/server-nestjs) : sérialisation par défaut des HttpException : { "message": "<message métier>", "error": "<raison HTTP générique>", "statusCode": ... }
- NestJS, validation Zod (
ZodValidationPipe) : BadRequestException(error.flatten()) → le body est l'objet flatten brut ({ formErrors, fieldErrors }), sans message ni error
Côté client, extractData (xhr-client.ts) doit deviner où se trouve le message (body.message ?? body.error ?? 'Erreur inconnue' depuis #2321). Les erreurs de validation Zod v2 s'affichent encore « Erreur inconnue ».
Proposition : ajouter un ExceptionFilter global dans apps/server-nestjs pour normaliser le format des erreurs v2, et y traiter le cas Zod (aplatir les fieldErrors en message lisible).
⚠️ Décision d'équipe requise : le format cible n'est pas qu'un détail technique — il faut un choix d'équipe sur la façon dont on gère les exceptions et le error handling à travers nos apps (server legacy, server-nestjs, client), notamment :
- quel contrat d'erreur pour l'API v2 (aligné sur le legacy
{ message } ? format NestJS enrichi ? RFC 7807 / problem+json ?) ;
- comment exposer les erreurs de validation (Zod) au client de manière exploitable (affichage par champ ?) ;
- ce qu'on logue vs ce qu'on expose (le legacy renvoie la
stack en prod — à rediscuter) ;
- la stratégie de convergence du client une fois le format v2 stabilisé (simplification d'
extractData).
À mettre à l'ordre du jour d'une prochaine réunion technique avant implémentation.
PRs liées
À compléter une fois la décision prise.
Issues liées
Exemples simples
Sur POST /api/v2/projects/:projectId/environments avec des quotas dépassés, le client affichait « Bad Request » au lieu de « Le projet ne dispose pas de suffisamment de ressources : GPU. ». Avec un body invalide (Zod), il affiche encore « Erreur inconnue ».
Spécifications techniques
ExceptionFilter global enregistré dans apps/server-nestjs (via APP_FILTER ou useGlobalFilters), normalisant toutes les HttpException (et erreurs non gérées) vers le format d'erreur retenu par l'équipe.- Traitement dédié du body
flatten() de ZodValidationPipe.
- Adaptation d'
extractData côté client une fois le format stabilisé.
DĂ©finition du fini
Description
Les erreurs ne sont pas formatées de la même façon selon le serveur qui répond :
apps/server), erreurs gérées (ErrorResType) :{ "message": "..." }setErrorHandlerdansapp.ts) :{ "status": 500, "error": "<message>", "stack": "..." }apps/server-nestjs) : sérialisation par défaut desHttpException:{ "message": "<message métier>", "error": "<raison HTTP générique>", "statusCode": ... }ZodValidationPipe) :BadRequestException(error.flatten())→ le body est l'objet flatten brut ({ formErrors, fieldErrors }), sansmessagenierrorCôté client,
extractData(xhr-client.ts) doit deviner où se trouve le message (body.message ?? body.error ?? 'Erreur inconnue'depuis #2321). Les erreurs de validation Zod v2 s'affichent encore « Erreur inconnue ».Proposition : ajouter un
ExceptionFilterglobal dansapps/server-nestjspour normaliser le format des erreurs v2, et y traiter le cas Zod (aplatir lesfieldErrorsen message lisible).{ message }? format NestJS enrichi ? RFC 7807 / problem+json ?) ;stacken prod — à rediscuter) ;extractData).À mettre à l'ordre du jour d'une prochaine réunion technique avant implémentation.
PRs liées
À compléter une fois la décision prise.
Issues liées
extractData)Exemples simples
Sur
POST /api/v2/projects/:projectId/environmentsavec des quotas dépassés, le client affichait « Bad Request » au lieu de « Le projet ne dispose pas de suffisamment de ressources : GPU. ». Avec un body invalide (Zod), il affiche encore « Erreur inconnue ».Spécifications techniques
ExceptionFilterglobal enregistré dansapps/server-nestjs(viaAPP_FILTERouuseGlobalFilters), normalisant toutes lesHttpException(et erreurs non gérées) vers le format d'erreur retenu par l'équipe.flatten()deZodValidationPipe.extractDatacôté client une fois le format stabilisé.Définition du fini