← Journal technique
EduQate·intégrité des données·2026-07-14

Le même bug quatre fois, trois causes

Under NestJS ValidationPipe whitelist: true, a DTO property with no class-validator decorator is stripped from the payload silently — the same symptom from three different causes.

Ça disait que ça marchait

Vert, 200, enregistré, « déjà géré » — et faux. Aucune erreur sur laquelle s'appuyer.

D'abord sur program-fees, à cause de l'import type ci-dessus. Puis le symptôme identique sur document-requirements pour une autre raison : ce DTO n'avait aucun décorateur class-validator du tout, juste des déclarations nues. Une propriété sans décorateur n'est pas reconnue sous whitelist: true, donc toute la charge est retirée.

Troisième fois sur la soumission de formulaire, où FormAnswer.value est une vraie union (string | string[] | number | boolean | null) parce que la forme d'une réponse dépend du type de champ. Personne ne l'avait décorée parce qu'aucun @IsString()/@IsNumber() unique n'est correct pour une union — ce dont j'ignorais qu'il y avait une réponse jusque-là : @IsDefined() accepte n'importe quelle valeur et exige juste que la clé soit là.

Après le deuxième j'ai arrêté de corriger ça un par un et j'ai grepé le pattern directement — des classes DTO avec des déclarations et aucun décorateur préfixé @Is. Ça a attrapé application-requests.dto.ts avant que je n'y brûle un quatrième cycle. Quand une cause racine se révèle être une convention non documentée, ratisse-la immédiatement au lieu de trébucher sur chaque instance.