fix(admin-monitoring): remplace le filtre resourceType cassé par une vérification manuelle #32

Merged

kyuno merged 1 commit from fix/admin-monitoring-intercept into fix/step-counter-scoped-to-direct-children

2026-09-05 11:30:40 +02:00

kyuno commented

2026-09-05 11:21:33 +02:00

Owner

Empilée sur #31 (encore non mergée) — voir stack-branches-on-unreviewed-pr.

Bug

admin-monitoring.cy.ts — "renders one card per service with its status and details" échouait de façon reproductible (pas un flake ponctuel) : cy.wait("@getMonitoring") en timeout ("No request ever occurred"), la page restant bloquée sur son état d'erreur "Impossible de charger les données, réessayez plus tard".

Repéré sans lien avec #31 en relançant la suite e2e complète après le correctif de visibilité flaky de recipe-form.feature (celui-là bien inclus dans #31).

Diagnostic

Isolé par une série de tests ciblés (détail en commentaire dans le code) :

Un intercept {resourceType: "fetch"} sans filtre d'URL ne voit jamais passer /admin/monitoring, seulement /admin/auth/me — alors que les deux appels viennent du même AdminApiClient, avec le même mécanisme fetch().
Pourtant, lire req.resourceType depuis l'intérieur d'un handler matché par url/method seuls (sans filtre resourceType déclaratif) renvoie bien "fetch" pour cette requête, de façon fiable et reproductible sur plusieurs runs.

Conclusion : la requête est correctement typée, mais le filtrage déclaratif par resourceType de Cypress 13.17.0 ne la capte plus sur le Chrome 152 de cette machine — probablement un décalage de compatibilité entre cette version de Cypress et un Chrome plus récent que ce qu'elle a été testée contre.

Correctif

Remplace le matcher déclaratif par un handler de fonction qui lit req.resourceType manuellement : laisse passer la requête de document (cy.visit() lui-même — même URL que l'API quand VITE_API_URL est vide, comme en CI) via req.continue(), et ne stub que le reste. Vérifié stable sur 3 runs consécutifs.

Corrige au passage le test "shows an error state" qui passait pour la mauvaise raison : sans serveur API réel derrière, une requête non interceptée échoue aussi au niveau réseau — indiscernable d'un vrai 500 pour MonitoringPage's .catch(). Il est désormais aliasé et attendu comme le premier test, pour prouver qu'il dépend bien du mock plutôt que d'un échec réseau accidentel.

Vérification

pnpm lint : clean
pnpm --filter web build : clean
admin-monitoring.cy.ts seul : 2/2, stable sur 3 runs consécutifs
Suite e2e complète : 28/28 fichiers, 116/116 tests verts

🤖 Generated with Claude Code

Empilée sur #31 (encore non mergée) — voir [[stack-branches-on-unreviewed-pr]]. ## Bug `admin-monitoring.cy.ts` — "renders one card per service with its status and details" échouait de façon reproductible (pas un flake ponctuel) : `cy.wait("@getMonitoring")` en timeout ("No request ever occurred"), la page restant bloquée sur son état d'erreur "Impossible de charger les données, réessayez plus tard". Repéré sans lien avec #31 en relançant la suite e2e complète après le correctif de visibilité flaky de `recipe-form.feature` (celui-là bien inclus dans #31). ## Diagnostic Isolé par une série de tests ciblés (détail en commentaire dans le code) : - Un intercept `{resourceType: "fetch"}` **sans filtre d'URL** ne voit jamais passer `/admin/monitoring`, seulement `/admin/auth/me` — alors que les deux appels viennent du même `AdminApiClient`, avec le même mécanisme `fetch()`. - Pourtant, lire `req.resourceType` **depuis l'intérieur d'un handler** matché par url/method seuls (sans filtre resourceType déclaratif) renvoie bien `"fetch"` pour cette requête, de façon fiable et reproductible sur plusieurs runs. Conclusion : la requête est correctement typée, mais le **filtrage déclaratif par `resourceType`** de Cypress 13.17.0 ne la capte plus sur le Chrome 152 de cette machine — probablement un décalage de compatibilité entre cette version de Cypress et un Chrome plus récent que ce qu'elle a été testée contre. ## Correctif Remplace le matcher déclaratif par un handler de fonction qui lit `req.resourceType` manuellement : laisse passer la requête de document (`cy.visit()` lui-même — même URL que l'API quand `VITE_API_URL` est vide, comme en CI) via `req.continue()`, et ne stub que le reste. Vérifié stable sur 3 runs consécutifs. Corrige au passage le test "shows an error state" qui passait **pour la mauvaise raison** : sans serveur API réel derrière, une requête non interceptée échoue aussi au niveau réseau — indiscernable d'un vrai 500 pour `MonitoringPage`'s `.catch()`. Il est désormais aliasé et attendu comme le premier test, pour prouver qu'il dépend bien du mock plutôt que d'un échec réseau accidentel. ## Vérification - `pnpm lint` : clean - `pnpm --filter web build` : clean - `admin-monitoring.cy.ts` seul : 2/2, stable sur 3 runs consécutifs - Suite e2e complète : 28/28 fichiers, 116/116 tests verts 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-09-05 11:21:33 +02:00

fix(admin-monitoring): remplace le filtre resourceType cassé par une vérification manuelle

CI / lint (push) Failing after 24s

Details

CI / build (push) Successful in 1m53s

Details

CI / intent-service-test (push) Successful in 3m52s

Details

CI / e2e (push) Successful in 7m41s

Details

CI / test (push) Failing after 12m15s

Details

c1aba1f18c

`admin-monitoring.cy.ts` échouait de façon reproductible ("renders one
card per service": cy.wait timeout, "No request ever occurred").

Diagnostiqué par isolation : le matcher déclaratif `resourceType: "fetch"`
de Cypress 13.17.0 ne capte plus du tout la requête réelle de
AdminApiClient.getMonitoring() sur le Chrome 152 de cette machine — un
intercept `{resourceType: "fetch"}` sans filtre d'URL ne voit passer que
/admin/auth/me, jamais /admin/monitoring, alors que le `req.resourceType`
de cette même requête, lu depuis un handler matché par url/method seuls,
vaut bien "fetch" de façon fiable et reproductible. Le filtrage déclaratif
est cassé, pas la requête elle-même.

Remplace le matcher par un handler de fonction qui laisse passer la
requête de document (`cy.visit()` lui-même, sur la même URL que l'API en
same-origin/CI) via `req.continue()` et ne stub que le reste — vérifié
stable sur 3 runs consécutifs.

Corrige au passage le test "shows an error state" qui passait pour la
mauvaise raison : sans serveur API réel, une requête non interceptée
échoue aussi au niveau réseau, ce que MonitoringPage.catch() ne
distingue pas d'un vrai 500 — désormais aliasé et attendu comme le
premier test, pour prouver qu'il dépend bien du mock.

Suite e2e complète: 28/28 fichiers, 116/116 tests verts.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>