Description
CĂŽtĂ© server-nestjs, aucun filtre d'exception global n'est enregistrĂ© (pas de @Catch, pas de useGlobalFilters, pas d'APP_FILTER). Par consĂ©quent, lorsqu'une requĂȘte Prisma lĂšve une PrismaClientKnownRequestError de code P2025 (« An operation failed because it depends on one or more records that were required but not found »), l'erreur n'est pas un HttpException et le filtre par dĂ©faut de NestJS renvoie une 500 Internal Server Error au lieu d'une 404 Not Found.
C'est notamment le cas des appels findUniqueOrThrow / findFirstOrThrow / update / delete sur un id inexistant. Exemple concret : DeploymentDatastoreService.getDeploymentById utilise findUniqueOrThrow, donc PUT d'un déploiement avec un deploymentId inconnu retourne actuellement 500 au lieu de 404.
Le reste du code contourne le problÚme au cas par cas (findUnique + if (!x) throw new NotFoundException(...) dans project, environment, project-loader, etc.), ce qui est incohérent et facile à oublier.
Proposition : ajouter un filtre d'exception global (@Catch(PrismaClientKnownRequestError), enregistré via APP_FILTER) qui mappe une fois pour toute l'application :
P2025 â 404 Not Found
- (à considérer :
P2002 conflit d'unicitĂ© â 409 Conflict, P2003 violation de clĂ© Ă©trangĂšre â 400/409)
Cela permettra ensuite de supprimer les gardes if (!x) throw new NotFoundException redondantes et de laisser les *OrThrow remonter naturellement le bon code HTTP.
Etapes de reproduction
1. Se placer sur un projet existant
2. Envoyer PUT /api/v1/projects/:projectId/deployments/:deploymentId avec un :deploymentId inexistant (mais un UUID valide)
3. Observer la réponse HTTP
4. La réponse est 500 Internal Server Error, alors qu'on attend 404 Not Found
Logs
PrismaClientKnownRequestError:
Invalid `prisma.deployment.findUniqueOrThrow()` invocation
An operation failed because it depends on one or more records that were required but not found. No record was found for a query.
code: 'P2025'
Version de la console impactée
(Ă complĂ©ter â prĂ©sent sur la branche feat/deployment-value-sources-api / main selon avancement de la pile)
Définition du fini
Description
CÎté
server-nestjs, aucun filtre d'exception global n'est enregistrĂ© (pas de@Catch, pas deuseGlobalFilters, pas d'APP_FILTER). Par consĂ©quent, lorsqu'une requĂȘte Prisma lĂšve unePrismaClientKnownRequestErrorde codeP2025(« An operation failed because it depends on one or more records that were required but not found »), l'erreur n'est pas unHttpExceptionet le filtre par dĂ©faut de NestJS renvoie une 500 Internal Server Error au lieu d'une 404 Not Found.C'est notamment le cas des appels
findUniqueOrThrow/findFirstOrThrow/update/deletesur un id inexistant. Exemple concret :DeploymentDatastoreService.getDeploymentByIdutilisefindUniqueOrThrow, doncPUTd'un déploiement avec undeploymentIdinconnu retourne actuellement 500 au lieu de 404.Le reste du code contourne le problÚme au cas par cas (
findUnique+if (!x) throw new NotFoundException(...)dansproject,environment,project-loader, etc.), ce qui est incohérent et facile à oublier.Proposition : ajouter un filtre d'exception global (
@Catch(PrismaClientKnownRequestError), enregistrĂ© viaAPP_FILTER) qui mappe une fois pour toute l'application :P2025â 404 Not FoundP2002conflit d'unicitĂ© â 409 Conflict,P2003violation de clĂ© Ă©trangĂšre â 400/409)Cela permettra ensuite de supprimer les gardes
if (!x) throw new NotFoundExceptionredondantes et de laisser les*OrThrowremonter naturellement le bon code HTTP.Etapes de reproduction
1. Se placer sur un projet existant 2. Envoyer PUT /api/v1/projects/:projectId/deployments/:deploymentId avec un :deploymentId inexistant (mais un UUID valide) 3. Observer la réponse HTTP 4. La réponse est 500 Internal Server Error, alors qu'on attend 404 Not FoundLogs
Version de la console impactée
(Ă complĂ©ter â prĂ©sent sur la branche
feat/deployment-value-sources-api/mainselon avancement de la pile)Définition du fini