Conversation
Le client openapi-fetch rend { data, error } sans jamais lever d'exception.
Les pages ne lisaient que data, si bien qu'une requete en erreur et une
requete sans contenu produisaient le meme rendu : une page blanche servie en
200, invisible pour les visiteurs comme pour les moteurs de recherche.
Le tri se fait desormais en un seul endroit :
- resolveCmsOutcome() decide entre rendre, repondre 404 et signaler une
erreur ; fonction pure, couverte par 13 tests unitaires
- requireCmsData() applique la decision, journalise l'adresse appelee avec le
statut HTTP, puis rend le contenu ou interrompt le rendu
- les 12 pages concernees y passent : une adresse de detail inconnue repond
404, une panne du CMS repond 500 avec une page d'erreur
Les pages dont le contenu est statique et dont seules les metadonnees
viennent du CMS (charte, FAQ, CGU) restent tolerantes : une metadonnee
manquante ne justifie pas de faire echouer la page.
Un projet vitest "unit" tourne en environnement Node, sans navigateur : les
tests de logique pure ne dependent plus de Chromium et durent quelques
centaines de millisecondes.
Verifie en local : contenu identique sur les 16 URL de reference, adresses
mortes en 404, jeton invalide entrainant 500 partout, 41 erreurs ESLint
contre 43 auparavant, 250 tests verts.
DnzzL
added this pull request to stack #400
September 29, 2026 13:25
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cette branche s'attaque à une panne silencieuse : quand une requête vers Strapi échoue, le site ne le dit pas. Il sert une page blanche avec un code 200. Le visiteur croit à une page vide, et Google l'indexe comme valide.
Le défaut n'est pas théorique. Pendant la montée de version, un en-tête
Authorizationmal formé faisait répondre 401 à toutes les requêtes, et les dix-sept pages du site se sont affichées blanches sans qu'aucune alerte ne se déclenche. La cause tient en une ligne : le client openapi-fetch ne lève jamais d'exception, il rend{ data, error }, et les pages ne lisaient quedata.Le tri se fait désormais en un seul endroit
resolveCmsOutcome()décide, pour chaque page, entre rendre le contenu, répondre 404 et signaler une erreur. C'est une fonction pure, donc testable sans navigateur ni accès au CMS : treize cas la couvrent.requireCmsData()applique la décision, journalise l'adresse appelée avec le statut HTTP, puis rend le contenu ou interrompt le rendu.La règle distingue trois situations. Une erreur de requête produit un 500, car une page vide vaut moins qu'une panne avouée. Une adresse de détail qui ne correspond à aucune entrée produit un 404, sans quoi chaque lien périmé deviendrait un 500 et sortirait de l'index. Une page singleton dont le contenu manque produit elle aussi un 500, puisqu'il n'existe pas d'adresse alternative à proposer.
Les pages dont le contenu est statique et dont seules les métadonnées viennent du CMS, comme la charte, la FAQ et les CGU, restent tolérantes : une métadonnée manquante ne justifie pas de faire échouer une page entière.
Vérifications
Le contenu des seize URL de référence est identique avant et après. Les adresses de détail inexistantes passent de 200 à 404. Avec un jeton invalide, les onze pages qui dépendent du CMS répondent 500 et affichent une page d'erreur portant l'en-tête, la navigation et le pied de page, tandis que les trois pages statiques restent en 200. Le journal serveur nomme alors l'adresse fautive, par exemple
[cms] /projects-list : HTTP 401 Missing or invalid credentials.Les 250 tests passent, dont les 13 nouveaux. Le lint descend de 43 à 41 erreurs.
Ce que cette branche ne couvre pas
Un CMS qui répond 200 avec une relation vide reste invisible : c'est une autre classe de panne, qui demandera un détecteur plutôt qu'un garde-fou. Les redirections du CMS pointent par ailleurs vers des chemins internes anglais (
/projects/…) là où le public visite/projets/…, ce qui crée des chaînes de redirection en deux sauts ; c'est une donnée à corriger dans Strapi, pas du code.