From c1aba1f18c716031311a0315040401afdddb8b97 Mon Sep 17 00:00:00 2001
From: Nicolas <nicolaslef53@gmail.com>
Date: Sat, 5 Sep 2026 11:20:57 +0200
Subject: [PATCH] =?UTF-8?q?fix(admin-monitoring):=20remplace=20le=20filtre?=
 =?UTF-8?q?=20resourceType=20cass=C3=A9=20par=20une=20v=C3=A9rification=20?=
 =?UTF-8?q?manuelle?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

`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>
---
 apps/web/cypress/e2e/admin-monitoring.cy.ts | 50 ++++++++++++++-------
 1 file changed, 34 insertions(+), 16 deletions(-)

diff --git a/apps/web/cypress/e2e/admin-monitoring.cy.ts b/apps/web/cypress/e2e/admin-monitoring.cy.ts
index fd6ba78..733e184 100644
--- a/apps/web/cypress/e2e/admin-monitoring.cy.ts
+++ b/apps/web/cypress/e2e/admin-monitoring.cy.ts
@@ -53,21 +53,33 @@ describe("Admin monitoring", () => {
   });
 
   // The page route `/admin/monitoring` and the API path `GET /admin/monitoring`
-  // are identical — a plain `**/admin/monitoring` glob would also match the
+  // are identical — a plain `**/admin/monitoring` glob also matches the
   // `cy.visit()` document request (and whether that's same-origin or not
-  // depends on `VITE_API_URL`, which isn't set in CI). `resourceType: "fetch"`
-  // pins the intercept to the `AdminApiClient` XHR only.
-  const monitoringApi = {
-    method: "GET",
-    url: "**/admin/monitoring",
-    resourceType: "fetch",
-  } as const;
+  // depends on `VITE_API_URL`, which isn't set in CI).
+  //
+  // This used to be disambiguated with a declarative `resourceType: "fetch"`
+  // route matcher, but that stopped working (Cypress 13.17.0 on this
+  // machine's Chrome 152): the *declarative* `resourceType` matcher no
+  // longer catches this request at all — confirmed by logging every request
+  // Cypress hands to a `{resourceType: "fetch"}` intercept, which only ever
+  // saw `/admin/auth/me`, never `/admin/monitoring` — even though the very
+  // same request's own `req.resourceType`, read *inside* a handler matched
+  // by url/method alone, reliably reads back `"fetch"`. So the request *is*
+  // correctly typed; only the pre-filtering by that type is broken. Reading
+  // `req.resourceType` inside the handler and branching manually (as below)
+  // isn't affected by that bug and reproduced correctly in every check.
+  function interceptMonitoringApi(response: { statusCode: number; body: unknown }) {
+    return cy.intercept("GET", "**/admin/monitoring", (req) => {
+      if (req.resourceType === "document") {
+        req.continue();
+        return;
+      }
+      req.reply(response);
+    });
+  }
 
   it("renders one card per service with its status and details", () => {
-    cy.intercept(monitoringApi, {
-      statusCode: 200,
-      body: monitoringFixture(),
-    }).as("getMonitoring");
+    interceptMonitoringApi({ statusCode: 200, body: monitoringFixture() }).as("getMonitoring");
     cy.visit("/admin/monitoring");
     cy.wait("@getMonitoring");
 
@@ -85,11 +97,17 @@ describe("Admin monitoring", () => {
   });
 
   it("shows an error state when the request fails", () => {
-    cy.intercept(monitoringApi, {
-      statusCode: 500,
-      body: { code: 5000, message: "x" },
-    });
+    // Aliased and waited on (unlike the other tests' plain intercepts) so
+    // this genuinely proves the 500 came from the mock — without a live API
+    // server, an unmatched request fails at the network level too, which
+    // `MonitoringPage`'s `.catch()` can't tell apart from a real 500 (see
+    // the comment above `interceptMonitoringApi`, this is exactly the class
+    // of bug that let this test pass for the wrong reason before).
+    interceptMonitoringApi({ statusCode: 500, body: { code: 5000, message: "x" } }).as(
+      "getMonitoringError",
+    );
     cy.visit("/admin/monitoring");
+    cy.wait("@getMonitoringError");
     cy.contains("Impossible de charger").should("be.visible");
   });
 });