Gatsby: Erreur / ressources de page pour / non trouvées. Ne pas rendre React

Hiya!

Ce problème est devenu silencieux. Silencieux effrayant. 👻

Nous recevons beaucoup de problèmes, donc nous clôturons actuellement les problèmes après 30 jours d'inactivité. Cela fait au moins 20 jours depuis la dernière mise à jour ici.
Si nous avons manqué ce problème ou si vous souhaitez le garder ouvert, veuillez répondre ici. Vous pouvez également ajouter l'étiquette «non périmé» pour garder ce problème ouvert!
Pour rappel amical: la meilleure façon de voir ce problème, ou tout autre, résolu est d'ouvrir une Pull Request. Consultez gatsby.dev/contribute pour plus d'informations sur l'ouverture des RP, le tri des problèmes et la contribution!

Merci de faire partie de la communauté Gatsby! 💪💜

@antoinerousseau serait-il utile de fournir un meilleur stacktrace? Comme peut-être que c'était 404 ou peut-être que les données de page étaient invalides. Pour le moment, vous ne voyez pas vraiment de différence.

Selon vous, quelle pourrait être la meilleure façon d'avancer? L'avez-vous essayé vous-même en safari / safari mobile?

@wardpeet merci d'avoir examiné cela.
J'ai essayé avec le bureau Safari et je n'ai pas pu reproduire. Je ne possède pas d'iPhone.
Je ne sais pas comment procéder, car cela n'arrive que parfois et de manière aléatoire, mais un meilleur stacktrace ne peut pas nuire de toute façon.
Notez que cela ne s'est produit que 124 fois, avec 85% Mobile Safari, 10% Safari et 5% Chrome Mobile iOS. Différentes versions.
De plus, l'URL n'est pas toujours / . Je peux vous donner accès au compte Bugsnag si vous le souhaitez.

J'ai eu le même rapport de bogue aujourd'hui. Juste pour vous faire savoir que vous n'êtes pas seul.

Hiya!

Ce problème est devenu silencieux. Silencieux effrayant. 👻

Nous recevons beaucoup de problèmes, donc nous clôturons actuellement les problèmes après 30 jours d'inactivité. Cela fait au moins 20 jours depuis la dernière mise à jour ici.
Si nous avons manqué ce problème ou si vous souhaitez le garder ouvert, veuillez répondre ici. Vous pouvez également ajouter l'étiquette «non périmé» pour garder ce problème ouvert!
Pour rappel amical: la meilleure façon de voir ce problème, ou tout autre, résolu est d'ouvrir une Pull Request. Consultez gatsby.dev/contribute pour plus d'informations sur l'ouverture des RP, le tri des problèmes et la contribution!

Merci de faire partie de la communauté Gatsby! 💪💜

Rebonjour!

Cela fait 30 jours que rien n'est arrivé à ce sujet, donc notre sympathique robot de quartier (c'est moi!) Va le fermer.
Veuillez garder à l'esprit que je ne suis qu'un robot, donc si j'ai résolu ce problème par erreur, je suis HUMAN_EMOTION_SORRY . N'hésitez pas à rouvrir ce numéro ou à en créer un nouveau si vous avez besoin de quelque chose d'autre.
Pour rappel amical: la meilleure façon de voir ce problème, ou tout autre, résolu est d'ouvrir une Pull Request. Consultez gatsby.dev/contribute pour plus d'informations sur l'ouverture des RP, le tri des problèmes et la contribution!

Merci encore de faire partie de la communauté Gatsby! 💪💜

Voir la même chose.

• C'est assez souvent (nous le voyons quotidiennement).
• Presque tous Mobile Safari ou Safari.
• Presque toujours / , mais très rarement d'autres pages.
• Sentry donne le même stacktrace que Bugsnag avec le fil d'Ariane suivant:
  

Pareil ici. Pour une page autre que / index.

Dispositif
Marque | Huawei
Famille | DRA-LX5

OS
Nom | Android
Version | 8.1.0

Navigateur
nom | Chrome Mobile WebView
version | 70.0.3538

SDK
Nom | sentry.javascript.browser
Version | 5.12.1

Hiya!

Ce problème est devenu silencieux. Silencieux effrayant. 👻

Nous recevons beaucoup de problèmes, donc nous clôturons actuellement les problèmes après 30 jours d'inactivité. Cela fait au moins 20 jours depuis la dernière mise à jour ici.
Si nous avons manqué ce problème ou si vous souhaitez le garder ouvert, veuillez répondre ici. Vous pouvez également ajouter l'étiquette «non périmé» pour garder ce problème ouvert!
Pour rappel amical: la meilleure façon de voir ce problème, ou tout autre, résolu est d'ouvrir une Pull Request. Consultez gatsby.dev/contribute pour plus d'informations sur l'ouverture des RP, le tri des problèmes et la contribution!

Merci de faire partie de la communauté Gatsby! 💪💜

Encore un problème.

Je reçois également ce problème. gatsby develop fonctionne bien, mais gatsby build provoque la rupture de l'application avec "Erreur: ressources de page pour / non trouvées. Impossible de rendre React." au moment de l'exécution même si la construction elle-même réussit.

Cela pourrait-il être dû au fait que j'utilise Typescript?

J'ai essayé d'exécuter gatsby clean

Mise à jour / Solution possible : Pour moi, l'erreur a été causée parce que je n'avais qu'un fichier ".env.development" et non un fichier ".env.production". Je ne sais pas pourquoi cela a donné une erreur aussi ambiguë / déroutante et a empêché React de restituer. J'ai l'impression que le comportement attendu serait le même que celui qui se produit lorsque j'exécute gatsby develop . Lorsque j'exécute gatsby develop et que je n'ai pas de fichier .env.development, React effectue toujours le rendu, mais mon application plante car il manque les valeurs importantes.

J'ai le même problème. Mon application est hébergée sur aws et utilise cloudfront. J'ai une politique pour rediriger toutes les URL inexistantes vers la page 404.html avec le statut 200 . Cela semble étrange, mais c'est vraiment important pour l'une de nos fonctionnalités. Donc, au cas où je tape quelque chose comme my-test-site.com/some-not-existed-page window.pagePath serait /404.html ce qui est correct, mais publicLoader.loadPage somewhy essaie de ne pas charger un 404.html contenu de la page, mais /my-test-site.com/some-not-existed-page . En fait, il utilise window.location.pathname mais pas window.pagePath

J'ai reçu le même message d'erreur dans Sentry aujourd'hui: introuvable. Ne pas rendre React

Je rencontrais également ce problème. Pour moi, il était reproductible lors de l'utilisation d'importations nommées pour vos propres composants dans le fichier pages/index.js .

Exemple
import Layout from "../components/Layout"; ✅
import { Layout } from "../components"; 🚫

components/index.js ressemblerait à ceci:

import Layout from "./Layout"

export {
  Layout
};

C'était avec MacOS Catelina & Chrome Version 80.0.3987.149.
"gatsby": "^2.20.13",

Il est important de noter que j'utilise la variante expo gatsby.

J'ai également eu ce problème lors de l'exécution d'un gatsby build propre et la cause principale était une résolution dans mon package.json pour une vulnérabilité de package acorn (voir https://snyk.io/vuln/npm :gland):

"resolutions": {
   "acorn": "^7.1.1"
}

La suppression de cette résolution a résolu le problème pour moi.

Sortie de gatsby info :

  System:
    OS: macOS 10.15.4
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.10.0 - /usr/local/bin/node
    Yarn: 1.22.4 - ~/.yarn/bin/yarn
    npm: 6.14.4 - /usr/local/bin/npm
  Languages:
    Python: 2.7.17 - /usr/local/bin/python
  Browsers:
    Chrome: 81.0.4044.92
    Safari: 13.1
  npmPackages:
    gatsby: 2.20.20 => 2.20.20 
    gatsby-plugin-material-ui: 2.1.6 => 2.1.6 
    gatsby-source-graphql: 2.4.0 => 2.4.0 

Cela arrive encore beaucoup (plus de 4500 fois la semaine dernière):

Stacktrace sur Mobile Safari:

.cache/production-app.js:128:12

126  publicLoader.loadPage(browserLoc.pathname).then(page => {
127    if (!page || page.status === PageResourceStatus.Error) {
128      throw new Error(
129        `page resources for ${browserLoc.pathname} not found. Not rendering React`
130      )
131    }

Stacktrace sur Chrome Mobile:

/app-ac76ae7860adc4ef4414.js:1:179819

Chapelure:

Temps | Type | Erreur | Infos
- | - | - | -
4ms avant | DEMANDE | Erreur XMLHttpRequest | GET /page-data/app-data.json
5ms avant | DEMANDE | Erreur XMLHttpRequest | GET /page-data/index/page-data.json
6ms avant | DEMANDE | Erreur XMLHttpRequest | GET /page-data/app-data.json
7ms avant | DEMANDE | Erreur XMLHttpRequest | GET /page-data/index/page-data.json
10ms avant | DEMANDE | Erreur XMLHttpRequest | GET /page-data/app-data.json
10ms avant | DEMANDE | Erreur XMLHttpRequest | GET /page-data/index/page-data.json

La plupart d'entre eux se produisent sur Mobile Safari et Chrome Mobile:

Version Gatsby: 2.20.13

Vérifiez cette solution.
https://github.com/gatsbyjs/gatsby/issues/11461#issuecomment -459732145

Je n'utilise pas gatsby-plugin-offline donc il n'y a pas de service workers.

Y at-il des progrès? J'ai un problème et j'ai un plugin hors ligne, et je ne peux pas désactiver le plugin pour tester si des erreurs se produisent.

Je ne pense pas que cela ait quoi que ce soit à voir avec le plugin hors ligne. Nous constatons beaucoup de ces erreurs et ne les avons jamais utilisées.

Reproduire:

• Allez dans [exemple n'est plus nécessaire, voir ci-dessous], notez l'erreur dans la console et React non fonctionnel.
• Accédez à la page d'accueil avec le logo en haut à gauche.
• Revenez à la page d'origine en cliquant sur "Recherche" dans l'en-tête. La page fonctionne maintenant et les panneaux sont pliables.

Comment déboguer cela? Il n'y a pas de requêtes réseau 404 ou autre, donc je ne comprends pas ce qui se passe. Les versions locales sont les suivantes, mais les builds se produisent sur Netlify:

  System:
    OS: macOS 10.15.3
    CPU: (4) x64 Intel(R) Core(TM) i5-8210Y CPU @ 1.60GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.16.1 - ~/.nvm/versions/node/v12.16.1/bin/node
    Yarn: 1.22.4 - ~/.yarn/bin/yarn
    npm: 6.14.4 - ~/.nvm/versions/node/v12.16.1/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 81.0.4044.122
    Firefox: 75.0
    Safari: 13.0.5
  npmPackages:
    gatsby: 2.21.1 => 2.21.1
    gatsby-image: 2.4.0 => 2.4.0
    gatsby-plugin-graphql-loader: 1.0.2 => 1.0.2
    gatsby-plugin-module-resolver: 1.0.3 => 1.0.3
    gatsby-plugin-page-creator: 2.3.0 => 2.3.0
    gatsby-plugin-react-helmet: 3.3.0 => 3.3.0
    gatsby-plugin-sharp: 2.6.0 => 2.6.0
    gatsby-plugin-typescript: 2.4.0 => 2.4.0
    gatsby-source-contentful: 2.3.1 => 2.3.1
    gatsby-transformer-remark: 2.8.0 => 2.8.0
    gatsby-transformer-sharp: 2.5.0 => 2.5.0

Dans notre cas, nous avions une page comme exportation par défaut, puis une exportation nommée dans le fichier de page. Dès que quelque chose faisait référence à l'exportation nommée de l'extérieur du fichier d'échange, cela devenait très confus.

Le correctif consistait à supprimer toutes les exportations des pages, à l'exception de l'exportation des composants de page par défaut.

@thekevinbrown L'erreur que vous

@Undistraction à chaque fois que vous avez commencé ou actualisé la page avec le problème. Si vous avez commencé sur une page différente, ou si vous avez navigué de la page vers une page en état de marche, puis de retour, tout allait bien. Donc, fondamentalement, l'hydratation initiale échoue dans ce cas, tandis que si vous pouvez amener l'utilisateur sur une page différente où l'hydratation fonctionne, le téléchargement et l'affichage de la page cassée fonctionnent.

Cela aurait certainement été mieux comme une erreur de construction claire au lieu d'une erreur d'exécution obscure si cela était possible.

@thekevinbrown donc je pense que votre problème n'est pas lié à ce problème (qui est une erreur intermittente que personne n'a été en mesure de reproduire de manière fiable), donc je pense que même si vous voyez la même erreur, la cause est différente (et heureusement vous facilement réparé).

Cette erreur a été rencontrée sur notre site de production et la mise à niveau vers la dernière version de Gatsby (sortie il y a seulement 2 jours) a corrigé le bogue de Safari

Mise à niveau vers la dernière version de Gatsby. Le problème persiste

Je n'ai jamais vécu cela auparavant. Soudain, cela arrive à chaque fois. Uniquement en production 😢
Cela s'est produit après une mise à jour il y a 20 heures. Nous mettons régulièrement à jour les dépendances.
Donc, fondamentalement, le projet est en panne et je ne sais pas comment le faire fonctionner à nouveau.

J'ai essayé de rétablir les mises à jour à ce qu'elles étaient il y a 20 heures. N'a pas aidé.
Revenir à il y a 8 jours n'a pas aidé non plus.

Voici le projet avec de nouvelles mises à jour: https://vermehrungch-4utm3ymcd.now.sh/Vermehrung/
Et voici le dernier qui fonctionne il y a 8 jours: https://vermehrungch-9l709pu84.now.sh/Vermehrung/

Le retour des dépendances de Gatsby à ce qu'elles étaient il y a 9 jours a permis à une nouvelle version de fonctionner à nouveau 😆

Essayons maintenant d'isoler les causes de la dépendance de Gatsby.

Ok, dans notre cas:

• gatsby lui-même est certainement la cause
• versions jusqu'à 2.20.36 fonctionnent
• v2.21.2 et v2.21.3 ont l'erreur ci-dessus (j'avais testé la v2.21.17 plus tôt, même erreur)
• v2.21.0 a une erreur différente:
  idb-keyval-iife.min.js:1 Uncaught (in promise) DOMException: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing. at https://vermehrungch.gabriel-software.now.sh/idb-keyval-iife.min.js:1:353 at new Promise (<anonymous>) at https://vermehrungch.gabriel-software.now.sh/idb-keyval-iife.min.js:1:323 at async Object.handle (https://vermehrungch.gabriel-software.now.sh/sw.js:162:21)

Mise à jour: l'erreur se produit toujours dans gatsby v2.21.19

@barbalex pourriez-vous partager votre site avec nous? Si c'est privé, envoyez un e-mail à [email protected].

J'obtiens cette erreur sur votre site lorsque je le débogue

[].concat(function(e) {
                if (Array.isArray(e)) {
                    for (var t = 0, n = Array(e.length); t < e.length; t++) n[t] = e[t];
                    return n
                }
                return Array.from(e)
            }(Object.keys(it.propTypes)), ["children"]);

Trace de la pile:

TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at Module.zJQU (VM54 component---src-pages-vermehrung-js-c3ca1cb1b4686475777d.js:13787)
    at c (webpack-runtime-2b4bd8eda0563b1ea7e6.js:1)

Le site est:

• https://vermehrung.ch
• https://github.com/barbalex/vermehrung
• vous pouvez même vous connecter en utilisant le mot de passe envoyé par e-mail

Le site est en développement. Ainsi, vous pouvez même modifier les données.

Nous avons reçu les mêmes messages d'erreur dans Sentry de manière récurrente:

Nous utilisons la version "2.21.22" de Gatsby.

J'ai rencontré le même problème et résolu en rétrogradant à la v2.20.36, mentionnée ci-dessus.

Ok, dans notre cas:

• gatsby lui-même est certainement la cause
• versions jusqu'à 2.20.36 fonctionnent
• v2.21.2 et v2.21.3 ont l'erreur ci-dessus (j'avais testé la v2.21.17 plus tôt, même erreur)

Je suis tombé dessus à nouveau dans un projet différent qui avait la version 2.21.12. C'est vraiment mauvais car cela se produit uniquement en production. Veuillez donner la priorité à ce bug.

Nous le voyons en production sur https://www.voteamerica.com/. Cela se produit principalement sur Mobile Safari, mais nous le voyons également sur Android Chrome, Safari de bureau, Chrome de bureau et autres. Nous utilisons actuellement Gatsby 2.21.40, mais nous voyions également le problème sur 2.20.12

Vous avez le même problème pour la page qui a été supprimée récemment. https://intergiro.com/legal n'affiche pas la page 404 personnalisée comme prévu (bureau Chrome, Gatsby 2.20.8). Se produit également uniquement en production.

Dans mon cas, le commentaire de @Kanuny a indirectement résolu mon problème. J'ai accidentellement redirigé les données de page JSON vers un fichier HTML lorsque publicLoader.loadPage essayait de les récupérer. Après avoir corrigé les redirections, les données de page JSON se chargent correctement et tout fonctionne comme d'habitude.

Le bogue a soudainement disparu à nouveau. On dirait qu'il pourrait être lié au cache ou à quelque chose

L'erreur se produit toujours dans la version 2.22.12 sur les dernières versions de Firefox et Chrome également.

Regle-le, s'il te plait!

Regle-le, s'il te plait!

@SoldierCorp , lisez ce qu'est l'Open Source et essayez peut-être de le réparer vous-même.

@antoinerousseau c'est aussi s'entraider, là où ceux qui ont besoin d'aide - le demandent, et ceux qui savent comment - l'offrir. Je pense donc que votre commentaire est déplacé.

@andrzejwp oui, il s'agit de s'entraider, pas de publier des commentaires autoritaires comme «s'il vous plaît, corrigez-le! sans informations utiles pour résoudre le problème, tout en informant 25 personnes suite à ce problème.

D'autres ont commenté avec des informations détaillées sur la façon dont cela les affecte, ce qui est nécessaire pour que les contributeurs les aident et, espérons-le, résolvent les problèmes d'OSS.

@antoinerousseau Il n'y a plus d'informations utiles liées à celle-ci car il n'y a plus d'informations fournies par le problème, donc cela arrive, alors j'ai écrit cela pour éviter de répéter les mêmes choses que d'autres personnes écrivent car c'est la même chose à la fin jusqu'au dernière version.

C'est juste pour faire savoir à Gatsby que plus de personnes rencontrent toujours le problème et qu'il n'a pas encore été résolu.

Désolé si cela vous dérange mais je suis un utilisateur régulier qui utilise le framework et pour ne pas avoir le temps de résoudre le problème par moi-même.

Dans mon cas, cela ne se produisait que lors du préfixe des chemins, car j'essaie d'utiliser gatsby-plugin-ipfs (exécuter gatsby build --prefix-paths && gatsby serve donnerait une "Erreur / ressources de page pour / non trouvées. Ne pas rendre React" pour chaque page).
Cependant, dans ma page index.jsx, je n'exécutais aucune requête de page, mais j'avais un composant qui contenait un staticQuery, du hook useStaticQuery.
Si je commentais ce composant et que je le reconstruisais, l'erreur disparaîtrait.
Il est intéressant de noter que si je décommente ce composant et que je le reconstruit à nouveau (pour que le site soit de retour dans l'état initial), il fonctionnerait correctement et ne rencontrerait pas l'erreur "Erreur / ressources de page pour / non trouvées. Ne pas rendre React", suggérant que le cache de construction contient quelque chose d'important?

Donc, mes pensées (grossières) sur les raisons pour lesquelles cela pourrait se produire sont:

• Problèmes avec la page d'index contenant une requête statique, mais pas une requête de page?
• Problèmes avec l'ordre du processus de construction (car la mise en cache peut modifier les résultats).
• Potentiellement un problème avec run static queries ou Generating image thumbnails dans le processus de construction, car ce sont les seules étapes qui semblent être ignorées grâce au cache.

J'ai accidentellement redirigé les données de page JSON vers un fichier HTML

Situation similaire ici. Essentiellement, une expression rationnelle de directive nginx location correspondait également à /page-data/items/page-data.json alors qu'elle n'aurait pas dû. L'ajout d'un ^ au début de l'expression rationnelle a évité la correspondance involontaire.

Nous le voyons en production sur https://www.voteamerica.com/. Cela se produit principalement sur Mobile Safari, mais nous le voyons également sur Android Chrome, Safari de bureau, Chrome de bureau et autres. Nous utilisons actuellement Gatsby 2.21.40, mais nous voyions également le problème sur 2.20.12

Face au même problème.

Salut l'équipe Gatsby, salut tout le monde. Serait-il possible de spécifier les erreurs renvoyées dans loadPage qui semblent être la source des diverses erreurs apparues dans ce problème?

Référez-vous à la fonction: https://github.com/gatsbyjs/gatsby/blob/030d927cddbdc64f8d93d409a5ada7442d5e62bf/packages/gatsby/cache-dir/loader.js#L179 -L242

Je crois comprendre que cette fonction essaie de charger app-data.json , page-data.json puis les composants JS eux-mêmes, étant ainsi très sujet aux problèmes de réseau, aux problèmes de configuration du serveur, aux problèmes de développement, aux problèmes de configuration ... En spécifiant le message d'erreur, il serait plus facile de résoudre les problèmes sous-jacents.

(Pour référence: la dernière occurrence de ce problème sur notre site Web était due à une importation circulaire)

J'ai essayé à nouveau avec la v2.23.12. Même résultat: https://vermehrungch-1j64x2olp.vercel.app/Vermehrung

Cela nous semble absolument systématique depuis chaque version supérieure à 2.20.36. Sur chacune des cinq applications créées à l'aide de gatsby. Nous avons donc été bloqués de la mise à jour depuis.

Ce qui commence à devenir un peu un problème. Par exemple, nous ne pouvons pas utiliser de bibliothèques utilisant core-js dans la v3 (https://github.com/gatsbyjs/gatsby/issues/15601). Ce problème a maintenant été résolu - si nous pouvons mettre à jour.

S'il y a un moyen que je puisse aider avec des informations / tests / quoi que ce soit, je le ferais volontiers.

@barbalex Vous avez l'erreur suivante dans votre application:

Nous devons absolument montrer cette erreur. N'hésitez pas à ajouter un PR, je n'ai pas assez de bande passante pour faire ce guichet automatique.

Il semble que ce problème soit dans notre cas causé par react-contextmenu lorsque cette lib est utilisée côté serveur: https://github.com/vkbansal/react-contextmenu/issues/284 , qui semble être déclenché pendant le processus de construction.

@wardpeet

N'hésitez pas à ajouter un PR, je n'ai pas assez de bande passante pour faire ce guichet automatique

Désolé de dire, je ne semble pas avoir assez de cellules grises pour cela 😢
Peut-être que @ b4stien le fait?

Le problème persiste toujours sur la version 2.23.21

Je n'ai pas de solution fourre-tout pour cela, mais je voulais juste que l'on sache que j'ai eu ce problème ce matin pour la première fois.

Et j'ai réussi à le "réparer".

Le site est hébergé sur AWS via un fournisseur appelé «Cloudways».

En guise de test initial, j'ai déployé le site sur Netlify - Et tout a bien fonctionné.

Après avoir fouillé un peu, il semblait y avoir un problème de cache côté serveur en utilisant quelque chose appelé "Varnish".

J'ai d'abord essayé de le «purger», et rien ne s'est passé - mais le désactiver et le réactiver a fonctionné.

Ce site existe depuis environ 18 mois dans cet environnement avec des mises à jour régulières, et c'était la première fois que je rencontrais ce problème.

Je suis récemment passé à:
Version CLI Gatsby: 2.12.59

Je ne sais pas si cela aurait pu avoir un effet, mais c'est le seul changement auquel je puisse penser - à moins bien sûr qu'il y ait eu un changement du côté de l'hébergement.

Espérons que cela aide quelqu'un là-bas 🤷

ÉDITER:

Le problème est revenu dans les 5 minutes lorsque j'ai réactivé le cache "vernis".

J'ai désactivé cette fonctionnalité pour le moment.

Dans notre cas, chaque page créée à partir du dossier /pages fonctionne mais le reste créé par createPages ne parvient pas à se réhydrater.
Nous rencontrons ce problème à la fois localement et CI.

dans notre cas, toutes les pages créées avec createPages , car nous utilisons l'internationalisation avec le préfixe /${locale}/ chaque page.

dans notre cas, toutes les pages créées avec createPages , car nous utilisons l'internationalisation avec le préfixe /${locale}/ chaque page.

Avez-vous trouvé une solution pour cela? nous avons également cette configuration avec de nombreux paramètres régionaux

@kdichev Non, je n'ai pas trouvé de solution. En attente de l'équipe Gatsby pour résoudre ce problème au niveau de la bibliothèque.

Je ne sais toujours pas où se trouve le problème, je serais heureux de faire un PR pour cela, mais j'aimerais que nous obtenions et trouvions où se trouve le problème sous-jacent?

Salut les gars, je suis confronté à ce problème lors de la production avec IE11.

"gatsby": "^ 2.23.11"

Egalement face à un résultat vierge (pas d'hydratation) de toutes les pages sur IE11.
Ressources de page pour / non trouvées. Ne pas rendre réagir

Gatsby v2.24.2

EDIT: Je suis revenu à la version de fonctionnement précédente v2.22.11. ie11 fonctionnait dans ce commit et à juste titre donc ça fonctionnait aussi maintenant, mais seulement quand j'ai conservé package-lock.json et npm ci. D'une manière ou d'une autre, je ne pense pas que ce soit gatsby dans le faux, donc je liste quelques changements possibles en aval qui peuvent être pertinents:
(version de travail -> version de construction défaillante)
les grands qui ne sont vraisemblablement candidats que pour les échecs ie11:
@ babel / core 7.10.0 -> 7.10.5
@ core / js 2.6.11 -> 3.6.5
gatsby-legacy-polyfills nouveau dep 0.0.2

autre moins probable:
@ graphql-tools / schema nouveau dep 6.0.14
@ graphql-tools / utils nouveau dep 6.0.14
et puis ma patience de passer au crible tout le rouge-> tout le vert dans l'outil de comparaison vscode s'est épuisé

Autres choses à noter: j'ai reproduit l'erreur avec gatsby build && gatsby serve -H 0.0.0.0, ce qui exclut tout élément côté environnement serveur.

EDIT 2: La sortie de construction de la version fauly v2.24.2 rapportée pour la première fois dans mon article est passée de 10 Mo à 30 Mo. Il a environ 20 versions de app- {hash} .js, 2 de commons- {hash} .js et divers nombres de pages.js. Il semble que ce ne soit pas tout à fait les mêmes fichiers et ils sont datés pour correspondre aux versions précédentes. Il semble donc que gatsby build ait en quelque sorte mis la main sur toutes les anciennes versions disponibles et les a jetées dans / public.

Quelqu'un peut-il partager un référentiel?

@roffelsaurus pouvez-vous essayer 2.23.22?
pour nous, 2.24.2 échoue dans les tests de cyprès ci / cd.

Quelqu'un peut-il partager un référentiel?

nous pouvons partager notre repo et nos vars en privé, si cela vous convient, veuillez m'envoyer un e-mail à konstantin. [email protected] et je vous inviterai à notre gh

@wardpeet, vous pouvez tester ce problème dans le référentiel auquel je vous ai donné accès lié au problème # 25766

Dans mon cas, le problème était lié à la commande import et à la façon dont certaines bibliothèques (à savoir react-leaflet ) sont gérées dans un environnement de rendu côté serveur. Nous avions un plugin de dépliant importé avant le dépliant lui-même causant le problème plus tard. J'ai pu le réparer assez rapidement une fois que j'ai su où chercher.

Cependant, je pense que le message d'erreur qu'il a généré ( page resources for / not found. Not rendering React ) était incroyablement déroutant et que le manque de détails et d'autres erreurs était le principal problème car j'ai dû creuser assez profondément pour savoir ce que cela signifie même.

À toute autre personne ayant ce problème: comment l'ai-je trouvé? Bon vieux point d'arrêt et débogage dans Chrome. gatsby build && gatsby serve autorisé à voir l'environnement de production localement avec toutes les cartes sources en place. J'ai pu déboguer quel morceau, puis le composant ne parvient pas à se charger et à jouer avec les importations à l'intérieur. C'était un processus plutôt lent, alors soyez patient car vous rechargerez la page encore et encore. Recherchez votre nom de bloc (dans mon cas, c'était component---src-pages-index-js ) et l'importation qui lui était assignée. Entrez-y et observez ses dépendances car l'une d'elles échouera. Je crois que dans chaque cas, ce sera différent, c'est pourquoi vous ne pouvez trouver aucune bonne solution nulle part. Les cartes sources se sont révélées utiles car elles m'ont montré plus qu'une simple série de promesses génériques dans le tableau.

Ce n'est pas le cœur du sujet, mais je vais laisser les détails de ce que j'ai découvert ci-dessous. Gardez toutefois à l'esprit que ci -

Donc, voici comment c'était à l'origine:

import { Map, Marker, Popup, TileLayer } from 'react-leaflet'
import "leaflet-control-geocoder/dist/Control.Geocoder"
import L from "leaflet";

et voici à quoi ça ressemble maintenant:

import { Map, Marker, Popup, TileLayer } from 'react-leaflet'
import L from "leaflet";
import "leaflet-control-geocoder/dist/Control.Geocoder"

Bien sûr, c'est une erreur de notre part, car tout plugin devrait généralement venir après la bibliothèque dans laquelle il est connecté. Puisque react-leaflet (je pense) change un peu l'ordre de chargement lors de l'exécution du débogage, le problème n'était pas visible pendant le développement.

Je viens de déboguer Uncaught (in promise) Error: page resources for /app/ not found. Not rendering React dans mon application. Dans mon cas, / app / est une route réservée au client qui contient une application de réaction. Je n'ai eu aucun problème dans gatsby develop , mais j'ai eu cette erreur lors de l'exécution de gatsby serve et aussi sur la version de production. Aucune erreur de construction n'a été signalée.

Il s'avère que les problèmes étaient avec react-contextmenu (https://github.com/vkbansal/react-contextmenu/issues/284) que @barbalex a également rencontré. Je ne sais pas si c'est la "faute" de react-contextmenu ... il semblerait que la bibliothèque recherche des responsables et l'auteur s'est probablement concentré sur l'implémentation côté client plutôt que côté serveur. Je ne sais pas si Gatsby peut faire quelque chose pour faciliter le débogage, le message d'erreur n'a pas été très utile.

@rgembalik , la façon dont j'ai débogué c'était en supprimant tous les composants de mon composant d'application, puis en les ajoutant un à un jusqu'à ce que je trouve le composant qui cassait la construction.

Pour moi, je ne peux même pas répliquer, je vois juste beaucoup de ces erreurs dans les rapports d'erreurs de sentinelle. donc je ne sais pas comment je vais comprendre

Nous en recevons beaucoup dans Sentry avec ces erreurs également pour toutes sortes de pages autres que "/", qui n'ont pas non plus pu se répliquer. Hébergé sur Netlify. Je soupçonne que cela peut avoir quelque chose à voir avec des sessions actives pendant les déploiements, mais difficile à vérifier.

@wardpeet semble qu'il existe de nombreuses causes potentielles différentes qui déclenchent cette même erreur. Pour nous, nous ne voyons ces erreurs que dans notre journal Sentry et n'avons jamais pu se reproduire. Serait-il possible d'inclure plus d'informations avec l'erreur ou d'ajouter plusieurs erreurs plus granulaires afin que nous ayons tous quelque chose de plus à faire pour essayer de rechercher la cause?

Je viens de recevoir cette erreur sur https://www.gatsbyjs.com/ se terminant par une page vierge

Je peux confirmer que lors du premier chargement de la page initiale, j'avais vu cette erreur sur gatsbyjs.com

J'ai compris que Gatsby avait une manière particulière de gérer les chemins d'URL avec des barres obliques. Je ne sais pas si cela peut aider

J'ai aussi ce problème.

Je ne suis pas en mesure de partager le référentiel, mais si vous accédez à cette page, vous pouvez voir qu'elle charge correctement un SVG. Mais, si je vais sur une route qui n'existe pas, ex https://rocketseat.com.br/test il affiche une version obsolète du code (qui utilise toujours gatsby-image au lieu d'un SVG) et montre moi ce message sur la console:

Error: page resources for /test not found. Not rendering React

J'utilise [email protected]

_edit: Je ne sais pas pourquoi, mais après avoir ajouté mon problème ici, le problème d'image a été résolu, mais je continue à recevoir la même erreur sur la page console_

Difficile pour moi de répliquer, je vois juste une tonne de ces erreurs dans les rapports d'erreurs de sentinelle

@theskillwithin - pareil. Des milliers de ceux-ci dans Sentry.

J'ai le même problème. Très étrange. Il semble que diverses causes déclenchent cette erreur.

Nous voyons également cette erreur se produire dans une variété de navigateurs et sur une variété de pages. Je n'arrive pas à relier notre situation à l'une des causes possibles susmentionnées. Et aussi je n'arrive pas à répliquer en développement - cela n'arrive qu'à notre site Web déployé.

J'ai le même problème. pas capable de reproduire mais des tonnes de ces erreurs en sentinelle. aussi une variété de navigateurs
gatsby version 2.24.3

Ceux-ci sont signalés semi-fréquemment dans un site de production où j'utilise également Sentry. Impossible de me répliquer. À mon avis, nous avons besoin de meilleurs rapports. Ce qui est bizarre à ce sujet, c'est qu'il trouve en fait les données de la page:

Puisqu'il reçoit un statut 200 et AFAICT, le json n'est pas mal formé, je suppose que fetchPageDataJson() renvoie une réponse de succès:
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L137 -L151

Puisque cela semble réussir, le prochain point d'échec que je peux voir serait le chargement du composant lui-même:
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L438 -L448
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L235 -L241

Il y a peut-être un problème dans les async-requires qui sont en cours d'écriture. J'imagine que ceux-ci sont en fait corrects, car ils seront gérés par Webpack, et le problème semble être intermittent. S'il y avait un problème avec la façon dont ce fichier est écrit, cela provoquerait un bombardement de la construction.

S'il s'agissait d'une sorte de problème de syntaxe quelque part dans le module importé, j'imagine que cela échouerait 100% du temps. Il y a peut-être quelque chose utilisé dans un module qui n'est pas compatible avec le périphérique / navigateur qui charge ledit module. Difficile à dire, bien sûr, car l'erreur spécifique est masquée.

Je pense que nous avons besoin du chargeur de composants pour _pas_ manger l'erreur qui est générée.

Avoir Promise.resolve() là quand un bloc n'existe pas dans asyncRequires signifie que l'erreur générée aurait du sens. Cette erreur serait également lancée à chaque visite sur cette page ... il serait donc facile d'en localiser la cause.

Renvoyer null dans le bloc catch signifie que l'erreur générée n'a pas de sens. Le module a été trouvé, mais une erreur s'est produite lors de l'importation dynamique. Webpack ne renvoie-t-il pas une erreur dans le bloc catch() d'une importation dynamique? Si ce n'est pas le cas, c'est peut-être un problème qui devrait être abordé avec Webpack. Je sais que si j'exécute un mauvais import() de devtools, une erreur est signalée ... qu'une erreur soit signalée ou non en raison de l'incapacité / l'échec de l'analyse du javascript importé est une autre question, et cela prendrait quelques tests supplémentaires avec du code que je _connais_ ne fonctionneront pas dans certains navigateurs.

@wardpeet vous avez mentionné un meilleur rapport d'erreur précédemment . Est-ce que cela est en cours ou une aide est-elle nécessaire?

En ce qui concerne la compatibilité du navigateur, je vois ces erreurs principalement générées par les appareils mobiles.

Mais j'ai également vu ces erreurs générées sur MacOS X avec Safari et Windows 10 avec Chrome.

Un point commun est que le trafic semble généralement provenir de Facebook ou de Google. Mais ce n'est peut-être qu'une coïncidence, car c'est ce qui alimente la majeure partie de notre trafic.

_REMARQUE: Ce site sur lequel je travaille utilise en fait [email protected] , donc le code auquel j'ai lié se trouve à différents endroits, mais la logique elle-même ne semble pas avoir changé. Il fait toujours la même chose, et les points de défaillance potentiels que j'ai identifiés semblent être les mêmes.

[email protected]

Je vois aussi rarement l'erreur sur bugsnag. Je ne sais pas si la page me rend ou non. Voici la pile sur bugsnag si cela peut aider @wardpeet Intéressant que dans ce cas, il semble avoir réessayé plusieurs fois. Notez que c'est l'une des nombreuses pages / webinar / blah ... sur lesquelles nous utilisons createPage (), mais bien sûr, si j'essaye de GET / page-data / ... comme indiqué sur la photo, cela fonctionne pour moi.

J'ajouterai des informations supplémentaires à l'erreur enregistrée, donc j'espère que nous pourrons trouver le problème

Je rencontre le même problème avec une page à l'origine d'un autre bogue publié sur https://github.com/gatsbyjs/gatsby/issues/26706

Dans mon cas, cela se produit dans (au moins) le chrome du bureau, et cela ne se produit que la première fois que je charge la page, si je clique sur Actualiser, tout s'affiche comme prévu

Ensuite, si j'essaie de répliquer cette première fois, même avec le mode incognito et en essayant d'effacer tous les cache auxquels je peux penser, je ne peux pas (parfois j'ai pu, très aléatoire cependant), avant un certain temps ( quelques jours) je visite l'url et trouve la même erreur (qui disparaît après avoir rafraîchi à nouveau)

Si j'essaie de le répliquer avec le même dépôt minimal que j'ai utilisé pour le problème lié ci-dessus, je ne suis pas en mesure de voir les mêmes erreurs (du moins pas les fois où j'ai essayé maintenant)

L'erreur est (dans ce cas) visible en raison de la non-création de la grille de maçonnerie, ce qui dans mon cas détruit la page à moins que l'utilisateur ne pense à actualiser la page (je pense que non)

En fait, c'est tellement aléatoire que je le vois depuis quelques semaines, mais j'ai toujours pensé que c'était quelque chose avec mon PC

J'ai couru npm auidit fix et le problème a été résolu pour moi.

Suivant! Avoir le même problème aussi

Salut,

Nous rencontrons également ce problème en production uniquement. Nous reproduisons ce bug 100% du temps sur des URL spécifiques. Voyons l'arborescence de notre public dir:

public
  icons
  page-data
  usages
    brainstorming
      page-data.json
    seminaries
      page-data.json

Lorsque nous entrons ces URL https://domain.com/usages/brainstorming cela fonctionne parfaitement, https://domain.com/usages/seminaries aussi. Si nous entrons une URL inconnue comme https://domain.com/doesnotexist nous avons légitimement la page 404, mais si nous essayons d'atteindre une URL qui correspond à un dossier réel dans l'arborescence, comme https://domain.com/usages , nous avons cette page vierge et cette erreur.

Cela vous rappelle-t-il quelque chose?

Meilleur

@guillaumepotier, est -ce que vous utiliserez également nginx?

Je pense que cela pourrait être causé par des en-têtes de réponse défectueux.

@ daydream05 oui en effet nous utilisons nginx. Nous avons vu dans nos journaux quelque 304 en-têtes de contenu non modifiés, et parfois 200 réponses.

à l'aide du compartiment AWS S3

Idem ici, hébergement dans AWS S3 (avec CloudFront CDN).

J'ai couru npm audit fix et le problème a été résolu pour moi.

Intéressant @ liuuuk311. Je l'ai essayé sur notre projet et il a peut-être résolu le problème pour nous aussi. Le temps nous le dira, mais jusqu'à présent, après 48h, il n'y a aucune occurrence dans nos journaux.

Edit: 5 jours plus tard, toujours pas d'occurrences ...

Edit: 10 jours plus tard et cela s'est reproduit plusieurs fois, désolé de le signaler. L'exécution de npm audit fix en soi ne semble pas résoudre le problème.

@wardpeet quelques données supplémentaires de bugsnag qui peuvent aider à diagnostiquer ...

Selon ceux-ci, il semble que les fichiers page-data.json se chargent correctement ...

• depuis que je suis tombé dessus aujourd'hui, je vais cogner * et regarder ici.

Dans mon cas, j'ai corrigé le problème de chargement de la lib polyfill.io dans la page

<script src="https://polyfill.io/v3/polyfill.min.js?version=3.52.1"></script>

@pedrofsantoscom veuillez expliquer comment un script chargé de manière statique résout un problème pour gatsby.js?

J'ai eu le même problème hier. La suppression du cache localement l'a corrigé pour l'utilisateur actuel. Nous avons donc vidé le cache de Cloudflare et maintenant nous ne recevons plus de rapports.
Effacer le cache était notre solution

Nous n'utilisons pas Cloudflare, nous utilisons AWS cloudfront CDN et il est invalidé après chaque déploiement. J'avais rencontré le bogue localement en exécutant le serveur Web local avec https avec la première tentative d'exécution après le démarrage du serveur Web et également dans certains rechargements de page conséquents, mais pas à chaque fois. Je ne vois aucun motif. Cela n'arrive que de temps en temps.

Nous n'utilisons pas Cloudflare, nous utilisons AWS cloudfront CDN et il est invalidé après chaque déploiement. J'avais rencontré le bogue localement en exécutant le serveur Web local avec https avec la première tentative d'exécution après le démarrage du serveur Web et également dans certains rechargements de page conséquents, mais pas à chaque fois. Je ne vois aucun motif. Cela n'arrive que de temps en temps.

C'était la solution pour nous. Lorsque nous avons vidé le cache, les erreurs par heure se sont réduites rapidement et nous n'avons pas eu au moins la même erreur dans bugsnag. C'est en effet une erreur étrange.

J'ai eu le même message d'erreur mais uniquement dans Internet Explorer. Tous les autres navigateurs n'ont pas affiché ce type de message d'erreur.

Unhandled promise rejection Error: page resources for / not found. Not rendering React

J'ai retracé le problème jusqu'à une importation que j'ai faite dans mes composants de réaction. Dans certains cas, j'avais des dépendances avec https://sap.github.io/ui5-webcomponents/ . Une fois que j'ai supprimé ces dépendances, le problème a disparu. Je ne peux pas expliquer quelle est la véritable cause profonde, mais je tiens à souligner que les dépendances dans vos contrôles de réaction peuvent causer ce problème.

@Chaosbohne ne peut pas vraiment discuter avec cela, mais je dirais même que c'est un problème de sous-dépendances. Je suppose que l'équipe gatsby.js se chargera de la gestion et de la sécurité des dépendances, et dans la première étape supprimera ^ de toutes les versions de dépendance / devDependency, toute la gamme de problèmes pourrait être évitée.

Je peux dire que ce problème ne dépend pas du navigateur. Je l'ai vu dans Chrome et Safari sur la base des journaux Sentry et dans Chrome 85, 86 localement sur mon mac.

Aucune des solutions ne fonctionne. @KyleAMathews à cause de ce problème, nous perdons des affaires, dans les 3-4 jours, ce problème se produit et nous ne sommes pas en mesure de trouver la cause profonde de celui-ci. Veuillez nous aider à trouver la solution à ce problème.

@ R3coN avez-vous essayé de reconstruire votre site Web? Quand cela nous est arrivé, nous avons simplement essayé à nouveau (c'était il y a quelque temps, je ne me souviens pas pourquoi cela a été corrigé)

@ R3coN si cela peut aider, voici les versions de package que nous utilisons qui fonctionnent bien:

    "gatsby": "2.20.36",
    "gatsby-cli": "^2.12.54",
    "gatsby-image": "^2.4.13",
    "gatsby-plugin-exclude": "^1.0.2",
    "gatsby-plugin-google-analytics": "^2.3.11",
    "gatsby-plugin-manifest": "^2.4.18",
    "gatsby-plugin-offline": "^3.2.17",
    "gatsby-plugin-react-helmet": "^3.3.10",
    "gatsby-plugin-react-svg": "^3.0.0",
    "gatsby-plugin-resolve-src": "^2.1.0",
    "gatsby-plugin-sass": "^2.3.12",
    "gatsby-plugin-sharp": "^2.6.19",
    "gatsby-plugin-use-query-params": "^1.0.1",
    "gatsby-source-filesystem": "^2.3.19",
    "gatsby-source-graphql": "^2.6.2",
    "gatsby-transformer-sharp": "^2.5.11",

@ shide1989 oui, c'est le seul moyen de le réparer, reconstruire à nouveau le site Web. Mais la reconstruction résout également le problème pendant 2-3 jours, puis ce problème survient. Nous utilisons la version CLI de Gatsby: 2.12.67 et la version Gatsby: 2.24.47 comme vous l'avez mentionné, la version 2.20.36 de gatsby fonctionne bien pour vous, nous tenterons notre chance en rétrogradant la version de gatsby.

@ shide1989 Merci pour le commentaire. Mais rétrograder la version me jette cette erreur ->

WebpackError: le résultat de cette StaticQuery n'a pas pu être récupéré.

Ce qui fonctionnait dans la version précédente 2.24.47.

désolé d'entendre cela, il vous manque peut-être un littéral de modèle étiqueté graphql dans le même fichier où le hook useStaticQuery est utilisé pour extraire les requêtes au moment de la construction. (comme décrit ici: https://github.com/gatsbyjs/gatsby/issues/24526)

en tout cas bonne chance avec ça

Mais je vous ai dit que le même code fonctionnait pour gatsby 2.24.47.

@ R3coN, ce problème peut également être causé par une mise en cache statique incorrecte. Si vous utilisez nginx ou s3 pour votre serveur et que vous n'invalidez pas votre page-data.json, vos StaticQueries se cassent chaque fois que vous modifiez vos données.

J'ai eu ce problème et il s'est avéré que je mettais en cache tout le fichier page-data.json. Ils ne devraient pas l'être. Ils doivent être revalidés à chaque demande

https://www.gatsbyjs.com/docs/caching/

@ daydream05 Merci pour le commentaire. Oui, j'utilise S3 avec CloudFront. Avez-vous une idée de comment y parvenir avec Cloudfront?

@ daydream05 J'ai déjà cache-control: 'public, max-age = 0, must-revalidate' ajouté à page-data.json et app-data.json ce qui signifie que ces pages ne sont pas mises en cache.

Je vois cela aussi sur des pages qui n'existent pas (qui devraient charger et hydrater la page 404).

Localement, mes builds de développement et de production fonctionnent sans cette erreur, et quand j'insère un console.log pendant la vérification qui lève cette erreur dans la production construite app-[hash].js , je peux voir que le page object existe et inclut page.componentChunkName: ""component---src-pages-404-js" comme je m'y attendais.

Cependant, lorsque l'application est déployée sur le cloud Gatsby, l'erreur se produit à chaque chargement d'une page inexistante. La page SSR'd 404 est affichée dans le navigateur, mais l'erreur est ensuite renvoyée, de sorte que React ne s'exécute jamais dans le navigateur. Lorsque la page 404 est chargée directement (en visitant le chemin /404 ), cela fonctionne correctement, sans erreur.

C'est difficile à diagnostiquer car je n'ai pas été en mesure de le reproduire localement jusqu'à présent.

Utilisation de la dernière version: "gatsby": "^2.24.91"

Il suffit de publier ceci ici pour permettre aux autres d'utiliser react-md pour réparer rapidement leur site, ou en espérant que cela pourrait aider de toute façon à résoudre ce problème dans Gatsby.

J'ai eu la même erreur dans l'un de mes projets, où j'utilisais react-md
Après avoir supprimé tous les composants, je pourrais me débarrasser du problème.

Depuis que j'ai dû déployer pour produire à chaque fois pour tester cela, je ne l'ai pas réussi à identifier quel composant spécifique a ce problème, mais je l'ai réduit à.

import Card from "react-md/lib/Cards/Card";
import CardTitle from "react-md/lib/Cards/CardTitle";
import CardText from "react-md/lib/Cards/CardText";
import CardActions from "react-md/lib/Cards/CardActions";
import { TextField, Button, Snackbar } from "react-md";

Je mettrai à jour mon article de blog sur ce problème si j'ai le temps de creuser plus profondément.

Concernant 404 pages, je peux confirmer le problème de

Localement, les versions de développement et de production fonctionnent bien avec la page 404 , mais une fois déployées sur Gatsby Cloud, j'obtiens le problème sur chaque page inconnue, à l'exception du chemin réel /404 .

J'ai également rencontré cette erreur et je l'ai corrigée en effaçant le cache du navigateur. Cependant, il serait bon de trouver une solution qui n'exige pas cela, car nous ne pouvons pas forcer toutes nos utilisations à le faire.

@ dejavu1987 nous n'utilisons pas

@MaciekBaron J'avais reproduit une erreur localement en effaçant le cache du navigateur plusieurs fois et en rechargeant la page après chaque effacement.

Cela semble être un problème de mise en cache, comme je l'ai mentionné plus tôt. Si vos en-têtes de cache sont tous définis correctement, le problème peut provenir des techniciens de service.

Peut-être essayer ce plugin?
https://www.npmjs.com/package/gatsby-plugin-remove-serviceworker

Hé, je rencontre aussi ce problème. En développement, tout fonctionne bien, mais lorsque j'exécute gatsby build et déploie le répertoire public sur mon hébergeur Web, une page ne fonctionne pas à cause de ce message d'erreur.

J'étais très curieux et j'ai regardé dans le répertoire public de données de page. J'ai trouvé que le répertoire de pages spécifique existe mais qu'il n'était pas en minuscule au lieu de cela, le répertoire était en majuscule. C'était le problème que j'ai eu le message d'erreur.

Après cela, je l'ai changé en petite lettre au début et cela fonctionne très bien en prod. Je pense que cela se produit parce que j'ai changé le nom de la page plus tôt et peut-être que quelque chose est mis en cache ici?

Je rencontre également ce problème. J'ai trouvé une méthode pour résoudre ce problème. Mais je pense que cela n'a pas réglé le vrai problème.

Maintenant, laissez-moi vous expliquer comment y remédier.

Ce problème a été trouvé dans l'environnement de test ou de production ， comme tout le monde le dit, il ne se reproduira pas en développement. Même en test ou en production, cela ne s'est pas produit à chaque fois. Et j'ai trouvé que tous les scripts étaient préchargés et exécutés de manière asynchrone. Donc je suppose que cela peut être causé par l'ordre exécutif des scripts.

Au fur et à mesure que je ralentis le réseau dans Network, tel que défini comme 3G fast , le problème s'est presque produit à chaque fois. Cela a confirmé ma supposition.

Pour valider mon hypothèse, j'ai modifié le processus de rendu HTML dans gatsby-ssr.js pour définir tous les scripts sans "async" , comme suit:

exports.onPreRenderHTML = ({ replacePostBodyComponents, getPostBodyComponents }) => {
    const postBodyComponents = getPostBodyComponents()
    postBodyComponents.forEach((component) => {
      if(component.type === 'script' && component.props) {
        delete component.props.async
      }
    })
    replacePostBodyComponents(postBodyComponents)
  }

Heureusement, ça marche.

Même si cette méthode peut aider à résoudre le problème, je ne pense pas que ce soit une bonne façon de le faire. Cela semble violer la fonctionnalité de Gatsby. Le script s'exécute-t-il de manière asynchrone comme ceci?

J'espère que cette méthode pourra également résoudre tous vos problèmes.

Ce problème a été trouvé dans l'environnement de test ou de production ， comme tout le monde le dit, il ne se reproduira pas en développement. Même en test ou en production, cela ne s'est pas produit à chaque fois. Et j'ai trouvé que tous les scripts étaient préchargés et exécutés de manière asynchrone. Donc je suppose que cela peut être causé par l'ordre exécutif des scripts.

Même si cette méthode peut aider à résoudre le problème, je ne pense pas que ce soit une bonne façon de le faire. Cela semble violer la fonctionnalité de Gatsby. Le script s'exécute-t-il de manière asynchrone comme ceci?

Je pense que vous avez raison, j'ai eu ce problème pour des raisons étranges.
Le dernier était sauvage, mais quand je le relie à votre réponse, cela a du sens.

Donc, récemment, j'ai ajouté un composant d'icône de police à mon composant de mise en page, et il a reproduit ce problème.
Un point important à noter est que les icônes de police ont été utilisées dans d'autres composants imbriqués profonds pendant tout ce temps, et cela n'a jamais causé le problème, uniquement lorsque c'est au niveau de la mise en page qui est le premier composant appelé à partir d'un composant de page.

Je me trompe peut-être, mais cela pourrait être un bon scénario pour déterminer la cause réelle.

@ dejavu1987 D'accord avec vous. Peut-être avez-vous donné un bon scénario pour déterminer la cause réelle.

De plus, je me demande s'il convient de charger et d'exécuter les scripts avec async , car le webpack divise les codes en différents morceaux mais les morceaux peuvent avoir des dépendances.

Le principal problème semble être que Gatsby avale les erreurs lors du chargement de la page et ne rapporte que le message très générique page resources for / not found. Not rendering React , c'est pourquoi il y a tant de causes potentielles différentes signalées dans ce fil.

Mon problème s'est avéré être que Mobx 5 ne prend pas en charge IE11, et bien que Mobx fournisse un bon message d'erreur pour cela, tout ce que j'ai obtenu était le message «ressources de page non trouvées» de Gatsby qui était plutôt trompeur.

Je suggère humblement comme résolution de ce problème de signaler le message d'erreur d'origine qui a provoqué l'échec du chargement de la page. @wardpeet

Ce qui a résolu le problème pour moi, c'est que S3 était configuré pour renvoyer un 200 sur la page 404. Lorsque je l'ai changé pour renvoyer un code d'état 404, cela a fonctionné.

Oui, j'ai trouvé ça aussi. Cependant, mon problème était plus large… Je mettais en cache incorrectement les résultats de Cloudfront 404. La raison pour laquelle j'obtenais 404 résultats entre Cloudfront et S3 est que le déploiement sur S3 via CodePipeline décompresse le fichier ZIP Build Artifact - mais il ne le fait pas dans un ordre particulier. Ainsi, pendant quelques minutes, vous pouvez avoir de nouveaux fichiers .HTML pointant vers de nouveaux fichiers .JS (avec de nouveaux hachages) qui ne sont pas encore là. Tout ce qui gère la mise en cache de vos fichiers d'actifs hachés ne doit pas mettre en cache les résultats 404 car cela ne peut être corrigé qu'en vidant votre cache CDN.

Quelqu'un a-t-il trouvé comment s'assurer que les fichiers HTML sont déployés en dernier sur S3?

David
https://ewebinar.com

Le 21 octobre 2020 à 12 h 40, Vince P. [email protected] a écrit:

@ R3coN https://github.com/R3coN ce problème peut également être causé par une mise en cache statique incorrecte. Si vous utilisez nginx ou s3 pour votre serveur et que vous n'invalidez pas votre page-data.json, vos StaticQueries se cassent chaque fois que vous modifiez vos données.

J'ai eu ce problème et il s'est avéré que je mettais en cache tout le fichier page-data.json. Ils ne devraient pas l'être. Ils doivent être revalidés à chaque demande

https://www.gatsbyjs.com/docs/caching/ https://www.gatsbyjs.com/docs/caching/
-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, visualisez-le sur GitHub https://github.com/gatsbyjs/gatsby/issues/19618#issuecomment-713298516 , ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/AA3SHT55MXZTXQUAXH5FSUYJBANCSLZM4 .

Je peux ajouter que j'avais reproduit un problème avec Chrome Lighthouse Audit sur les tests mobiles, avec des tests PWA et sans. Je suis sûr que les tests mobiles utilisent les limites du réseau et du processeur, donc le chargement des scripts async dans le désordre, ou l'un des 30 échouant ... peut être assez souvent une situation.

Je travaille avec 3d, et même à localhost avec webpack et gatsby.js , le rechargement de la page entraîne souvent des échecs de requêtes réseau pour le modèle statique gtlf des dossiers. L'un d'eux a échoué - toute l'application est cassée (si aucun ErrorBoundary n'est défini).

Je suppose qu'ici pourrait être le même modèle, mais sans gestion d'erreur appropriée.

J'utilise S3 et CloudFront pour la production. J'ai eu un problème similaire, mais dans mon cas, j'obtenais Can't render React erreur

Cela ne se produisait sur mon appareil qu'en mode normal. Dans mon cas, nettoyer tout le cache, les cookies, le stockage local, le stockage de session et les techniciens de service n'ont pas aidé plus tôt.

Donc, si vous profilez votre origine de production avec phare et que les fichiers ont été modifiés, ce problème peut également se produire (dans mon cas, c'était le cas)

Mon point est que je peux le reproduire avec le phare à peu près 1 sur 10, et le dernier déploiement remonte à longtemps.

Je ne pense pas que Gatsby pourra résoudre ce problème, car cela arrive à tout le monde mais la raison est différente. Je reçois des pages vierges trop souvent ou chaque fois que je change quelque chose dans le backend, la page gatsby devient vierge et génère une erreur, et cette erreur est également différente à chaque fois. Je pense que nous devons arrêter d'utiliser gatsby et passer à un autre cadre fiable.

Je pourrais corriger l'erreur s'il existe un moyen de la reproduire, mais ce n'est pas le cas. Cette erreur se produit de manière aléatoire, parfois cela se produit un jour après le déploiement, parfois cela se produit 3-4 jours après le déploiement. Mais ça arrive.

@antoinerousseau Avez-vous trouvé quelque chose? Quelqu'un peut-il me dire étape par étape comment déboguer au moins ce problème? J'ai essayé toutes les choses de mon côté mais 1 à 2 jours après le déploiement du site Web se brise. Quelqu'un peut-il me dire comment savoir quand ce problème se produira parce que pour moi, cela se produit de manière trop aléatoire?

Ce qui a résolu le problème pour moi, c'est que S3 était configuré pour renvoyer un 200 sur la page 404. Lorsque je l'ai changé pour renvoyer un code d'état 404, cela a fonctionné.

S3 ou Cloudfront?

Dans mon cas, le problème était dans la page 404, utilisée par défaut par Azure. C'était une erreur de blocage et la seule chose que j'ai pu voir dans la console était
Error / page resources for / not found. Not rendering React

Depuis que j'ai commencé à utiliser le 404 personnalisé - le problème a disparu.

J'obtiens la même chose lorsque je déploie l'application sur Netlify .. Localement, Gatsy Build et Gatsby Serve fonctionnent bien .. C'est encore plus étrange.

@atapas pouvez-vous s'il vous plaît contacter le support Netlify? peut-être peuvent-ils clarifier quelque chose de leur côté?

@atapas pouvez-vous s'il vous plaît contacter le support Netlify? peut-être peuvent-ils clarifier quelque chose de leur côté?

Oui je l'ai fait. Merci!

Peut-être qu'une meilleure trace de pile ou un message d'erreur clair serait utile ici. Quoi qu'il en soit, merci pour la réponse.

@atapas Je ne suis pas membre d'une équipe, je souffre juste du même bug que vous.

J'obtiens la même chose lorsque je déploie l'application sur Netlify .. Localement, Gatsy Build et Gatsby Serve fonctionnent bien .. C'est encore plus étrange.

J'ai trouvé la solution dans un contexte complètement différent. J'obtenais l'erreur car Netlify ignorait les variables d'environnement que j'avais définies pour qu'Auth0 fonctionne dans mon application,

domaine: process.env.AUTH0_DOMAIN,
clientID: process.env.AUTH0_CLIENTID,
redirectUri: process.env.AUTH0_CALLBACK,

J'ai lu plus tard sur le "Déployer sans variables sensibles" à partir d' ici et je l'ai corrigé comme il était mentionné dans la doc.

Je suis surpris par l'erreur que j'ai eue et la solution a atterri ... mais content que cela ait fonctionné.

@atapas Je ne suis pas membre d'une équipe, je souffre juste du même bug que vous.

@ JustFly1984 , Pas de soucis, je voulais vraiment vous remercier. J'ai regardé dans la documentation Netlify et j'ai pu trouver la solution comme mentionné dans le commentaire ci-dessus.

Je reçois cela uniquement dans Chrome. Safari fonctionne très bien. Je viens d'ajouter les plugins hors ligne et manifeste à mon projet. Je ne peux pas le reproduire avec Gatsby develop ou avec gatsby build & gatsby serve localement. J'héberge sur Netlify.

Pour moi, ce bloc de code en dehors de mon composant React ainsi que le référencement des variables globales dans le composant React étaient à l'origine de l'erreur. Le supprimer a résolu le problème.

let deferredprompt = null;
let updateAvailable = false;
if (
  typeof window !== "undefined" &&
  window.hasOwnProperty("BeforeInstallPromptEvent")
) {
  window.addEventListener("beforeinstallprompt", (event) => {
    deferredprompt = event;
    event.preventDefault();
  });
}

if (typeof window !== "undefined" && window.isUpdateAvailable) {
  window.isUpdateAvailable.then(
    (isAvailable) => (updateAvailable = isAvailable)
  );
}