next.validation échoue sur la route de conformité que le socle monte lui-même (conformite.valider n'est pas .strict()) #159

Closed
opened 2026-10-15 08:09:29 +00:00 by nicolas-fryder · 0 comments

Ce qui ne va pas

routesDeConformiteNext (packages/platform-next/src/testing/routes-conformite.ts, #149) déclare le corps de POST __eqs/conformite/valider en z.object({ nom: z.string(), quantite: z.number() }) sans .strict(). Le contrôle next.validation (packages/platform-next/src/conformite.ts, autour de la ligne 317) envoie ce corps avec champQuiNExistePas: 1 et exige 422 : la route du socle rend 200. La règle ne peut donc jamais passer dans un satellite next-fullstack qui s'appuie sur les routes de conformité du socle, c'est-à-dire sur ce que #149 promettait de rendre jouable.

Toujours présent sur main en 0.24.0 (même ligne 54).

Reproduire

Le gabarit eqs-satellite-template, variante next-fullstack, @eqs/* 0.23.0 (eqs --version → 0.23.0) :

  1. Poser la variante sur un clone (variantes/next-fullstack/README.md, « Le choix se fait à l'étape 2 »), puis pnpm install.
  2. Retirer la dispense next.validation d'eqs-baseline.json.
  3. pnpm --filter web test:integration
 FAIL  test/integration/conformite.test.ts > conformité @eqs (profil next-fullstack) > next
AssertionError:
  [bloquant] next.validation (POST /api/__eqs/conformite/valider)
    un champ inconnu rend 200, pas 422
    → body: z.object({ … }).strict() dans withApi

La suite du gabarit ne fournit pas de routeValidation à elle : c'est demarrerRoutes qui remplit routeValidation, corpsValide et champNombre à partir de a.conformite (testing/index.ts, vers la ligne 144).

Pourquoi eqs-demo ne le voit pas : sa suite passe sa propre route (routeValidation: '/api/demo/valider'), qui est stricte. Le chemin « routes de conformité du socle seules » n'est joué par personne.

Le message est d'ailleurs trompeur : il dit au satellite d'écrire .strict() dans son withApi, alors que la route fautive est celle du socle, que le satellite ne peut pas modifier.

Ce que ça coûte

Contournable, pas bloquant : la variante du gabarit garde la dispense datée next.validation (jusqu'au 2026-12-31), dont la raison pointe désormais vers ce ticket. Mais ce que la dispense couvre n'est plus « le profil n'a pas la route » : c'est « la route du socle est fausse ». Tout satellite next-fullstack neuf hérite de la dispense, ou d'un rouge s'il la retire en croyant #149 livré. Environ une demi-heure pour remonter du rouge au fichier.

Ce que je proposerais

  1. .strict() sur le corps de conformite.valider :
    body: z.object({ nom: z.string(), quantite: z.number() }).strict(),
    
  2. Un test du socle qui joue next.validation (et errors.validation) par demarrerRoutes sans routeValidation fournie par l'application, c'est-à-dire contre les seules routes de conformité. C'est le trou qui a laissé passer le défaut.
  3. Accessoirement : quand la route jugée est __eqs/conformite/*, que le faire du message dise que le défaut est dans le socle et pas chez le satellite.

Contournement, à retirer après correction

eqs-satellite-template, variantes/next-fullstack/eqs-baseline.json : dispense next.validation, raison renvoyant à ce ticket. À retirer à la montée qui corrige.

## Ce qui ne va pas `routesDeConformiteNext` (`packages/platform-next/src/testing/routes-conformite.ts`, #149) déclare le corps de `POST __eqs/conformite/valider` en `z.object({ nom: z.string(), quantite: z.number() })` **sans `.strict()`**. Le contrôle `next.validation` (`packages/platform-next/src/conformite.ts`, autour de la ligne 317) envoie ce corps avec `champQuiNExistePas: 1` et exige 422 : la route du socle rend 200. La règle **ne peut donc jamais passer** dans un satellite next-fullstack qui s'appuie sur les routes de conformité du socle, c'est-à-dire sur ce que #149 promettait de rendre jouable. Toujours présent sur `main` en 0.24.0 (même ligne 54). ## Reproduire Le gabarit `eqs-satellite-template`, variante next-fullstack, `@eqs/*` 0.23.0 (`eqs --version` → `0.23.0`) : 1. Poser la variante sur un clone (`variantes/next-fullstack/README.md`, « Le choix se fait à l'étape 2 »), puis `pnpm install`. 2. Retirer la dispense `next.validation` d'`eqs-baseline.json`. 3. `pnpm --filter web test:integration` ``` FAIL test/integration/conformite.test.ts > conformité @eqs (profil next-fullstack) > next AssertionError: [bloquant] next.validation (POST /api/__eqs/conformite/valider) un champ inconnu rend 200, pas 422 → body: z.object({ … }).strict() dans withApi ``` La suite du gabarit ne fournit pas de `routeValidation` à elle : c'est `demarrerRoutes` qui remplit `routeValidation`, `corpsValide` et `champNombre` à partir de `a.conformite` (`testing/index.ts`, vers la ligne 144). **Pourquoi eqs-demo ne le voit pas** : sa suite passe sa propre route (`routeValidation: '/api/demo/valider'`), qui est stricte. Le chemin « routes de conformité du socle seules » n'est joué par personne. Le message est d'ailleurs trompeur : il dit au satellite d'écrire `.strict()` dans son `withApi`, alors que la route fautive est celle du socle, que le satellite ne peut pas modifier. ## Ce que ça coûte Contournable, pas bloquant : la variante du gabarit garde la dispense datée `next.validation` (jusqu'au 2026-12-31), dont la raison pointe désormais vers ce ticket. Mais ce que la dispense couvre n'est plus « le profil n'a pas la route » : c'est « la route du socle est fausse ». Tout satellite next-fullstack neuf hérite de la dispense, ou d'un rouge s'il la retire en croyant #149 livré. Environ une demi-heure pour remonter du rouge au fichier. ## Ce que je proposerais 1. `.strict()` sur le corps de `conformite.valider` : ```ts body: z.object({ nom: z.string(), quantite: z.number() }).strict(), ``` 2. Un test du socle qui joue `next.validation` (et `errors.validation`) par `demarrerRoutes` **sans** `routeValidation` fournie par l'application, c'est-à-dire contre les seules routes de conformité. C'est le trou qui a laissé passer le défaut. 3. Accessoirement : quand la route jugée est `__eqs/conformite/*`, que le `faire` du message dise que le défaut est dans le socle et pas chez le satellite. ## Contournement, à retirer après correction `eqs-satellite-template`, `variantes/next-fullstack/eqs-baseline.json` : dispense `next.validation`, raison renvoyant à ce ticket. À retirer à la montée qui corrige.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-platform#159
No description provided.