Gatsby: Fehler- / Seitenressourcen für / nicht gefunden. Reagieren nicht rendern

Hiya!

Dieses Problem ist behoben. Gruselig leise. 👻

Wir haben viele Probleme, daher schließen wir Probleme derzeit nach 30 Tagen Inaktivität. Seit dem letzten Update hier sind mindestens 20 Tage vergangen.
Wenn wir dieses Problem verpasst haben oder wenn Sie es offen halten möchten, antworten Sie bitte hier. Sie können auch das Label "not stale" hinzufügen, um dieses Problem offen zu halten!
Zur freundlichen Erinnerung: Der beste Weg, um dieses oder ein anderes behobenes Problem zu erkennen, ist das Öffnen einer Pull-Anfrage. Check out gatsby.dev/contribute für weitere Informationen über PRs Öffnen Selektierung Fragen, und einen Beitrag!

Vielen Dank, dass Sie Teil der Gatsby-Community sind! 💪💜

@antoinerousseau würde es helfen, wenn wir eine bessere

Was ist Ihrer Meinung nach der beste Weg, um vorwärts zu kommen? Haben Sie es selbst auf einer mobilen Safari / Safari versucht?

@wardpeet danke, dass
Ich habe es mit Safari Desktop versucht und konnte es nicht reproduzieren. Ich besitze kein iPhone.
Ich bin mir nicht sicher, wie ich vorgehen soll, da es nur manchmal und zufällig passiert, aber eine bessere Stapelverfolgung kann sowieso nicht schaden.
Beachten Sie, dass dies nur 124 Mal passiert ist, mit 85% Mobile Safari, 10% Safari und 5% Chrome Mobile iOS. Verschiedene Versionen.
Außerdem lautet die URL nicht immer / . Ich kann Ihnen Zugriff auf das Bugsnag-Konto gewähren, wenn Sie möchten.

Ich habe heute den gleichen Fehlerbericht erhalten. Nur um dich wissen zu lassen, dass du nicht allein bist.

Hiya!

Dieses Problem ist behoben. Gruselig leise. 👻

Wir haben viele Probleme, daher schließen wir Probleme derzeit nach 30 Tagen Inaktivität. Seit dem letzten Update hier sind mindestens 20 Tage vergangen.
Wenn wir dieses Problem verpasst haben oder wenn Sie es offen halten möchten, antworten Sie bitte hier. Sie können auch das Label "not stale" hinzufügen, um dieses Problem offen zu halten!
Zur freundlichen Erinnerung: Der beste Weg, um dieses oder ein anderes behobenes Problem zu erkennen, ist das Öffnen einer Pull-Anfrage. Check out gatsby.dev/contribute für weitere Informationen über PRs Öffnen Selektierung Fragen, und einen Beitrag!

Vielen Dank, dass Sie Teil der Gatsby-Community sind! 💪💜

Hallo nochmal!

Es ist 30 Tage her, seit irgendetwas in dieser Angelegenheit passiert ist, also wird unser freundlicher Nachbarschaftsroboter (das bin ich!) Es schließen.
Bitte denken Sie daran, dass ich nur ein Roboter bin. Wenn ich dieses Problem also irrtümlich geschlossen habe, bin ich HUMAN_EMOTION_SORRY . Bitte öffnen Sie diese Ausgabe erneut oder erstellen Sie eine neue, wenn Sie etwas anderes benötigen.
Zur freundlichen Erinnerung: Der beste Weg, um dieses oder ein anderes behobenes Problem zu erkennen, ist das Öffnen einer Pull-Anfrage. Check out gatsby.dev/contribute für weitere Informationen über PRs Öffnen Selektierung Fragen, und einen Beitrag!

Nochmals vielen Dank, dass Sie Teil der Gatsby-Community sind! 💪💜

Das Gleiche sehen.

• Es ist ziemlich oft (wir sehen es täglich).
• Fast alle Mobile Safari oder Safari.
• Fast immer / , aber sehr selten andere Seiten.
• Sentry bietet die gleiche Stapelspur wie Bugsnag mit den folgenden Semmelbröseln:
  

Hier gilt das gleiche. Für eine andere Seite als / index.

Gerät
Marke | Huawei
Familie | DRA-LX5

Betriebssystem
Name | Android
Version | 8.1.0

Browser
Name | Chrome Mobile WebView
version | 70.0.3538

SDK
Name | sentry.javascript.browser
Version | 5.12.1

Hiya!

Dieses Problem ist behoben. Gruselig leise. 👻

Wir haben viele Probleme, daher schließen wir Probleme derzeit nach 30 Tagen Inaktivität. Seit dem letzten Update hier sind mindestens 20 Tage vergangen.
Wenn wir dieses Problem verpasst haben oder wenn Sie es offen halten möchten, antworten Sie bitte hier. Sie können auch das Label "not stale" hinzufügen, um dieses Problem offen zu halten!
Zur freundlichen Erinnerung: Der beste Weg, um dieses oder ein anderes behobenes Problem zu erkennen, ist das Öffnen einer Pull-Anfrage. Check out gatsby.dev/contribute für weitere Informationen über PRs Öffnen Selektierung Fragen, und einen Beitrag!

Vielen Dank, dass Sie Teil der Gatsby-Community sind! 💪💜

Immer noch ein Problem.

Ich bekomme auch dieses Problem. gatsby develop funktioniert einwandfrei, aber gatsby build dass die Anwendung mit "Fehler: Seitenressourcen für / nicht gefunden. Reagieren nicht" unterbrochen wird. zur Laufzeit, obwohl der Build selbst erfolgreich ist.

Könnte dies daran liegen, dass ich Typescript verwende?

Ich habe versucht, gatsby clean

Update / Mögliche Lösung : Für mich wurde der Fehler verursacht, weil ich nur eine ".env.development" -Datei und keine ".env.production" -Datei hatte. Ich weiß nicht, warum dies einen so mehrdeutigen / verwirrenden Fehler verursachte und React am Rendern hinderte. Ich habe das Gefühl, dass das erwartete Verhalten das gleiche ist wie das, was passiert, wenn ich gatsby develop ausführe. Wenn ich gatsby develop ausführe und keine .env.development-Datei habe, wird React immer noch gerendert, aber meine App stürzt ab, weil die wichtigen Werte fehlen.

Ich habe das gleiche Problem. Meine App wird auf aws gehostet und verwendet Cloudfront. Ich habe eine Richtlinie, um alle nicht vorhandenen URLs auf die Seite 404.html mit dem Status 200 umzuleiten. Das sieht seltsam aus, ist aber für eine unserer Funktionen sehr wichtig. Wenn ich also so etwas wie my-test-site.com/some-not-existed-page window.pagePath publicLoader.loadPage eingebe, wäre das /404.html was richtig ist, aber publicLoader.loadPage versucht irgendwie, kein 404.html zu laden Seiteninhalt, aber /my-test-site.com/some-not-existed-page . Tatsächlich werden window.location.pathname aber nicht window.pagePath

Ich habe heute die gleiche Fehlermeldung in Sentry erhalten: nicht gefunden. Reagieren nicht rendern

Ich bin auch auf dieses Problem gestoßen. Für mich war es reproduzierbar, wenn benannte Importe für Ihre eigenen Komponenten in der Datei pages/index.js verwendet wurden.

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

components/index.js würde so aussehen:

import Layout from "./Layout"

export {
  Layout
};

Dies war mit MacOS Catelina & Chrome Version 80.0.3987.149.
"gatsby": "^2.20.13",

Wichtig zu beachten ist, dass ich die Expo Gatsby-Variante verwende.

Ich hatte dieses Problem auch beim Ausführen eines sauberen gatsby build und die Hauptursache war eine Lösung in meiner package.json für eine acorn -Paket-Sicherheitslücke (siehe https://snyk.io/vuln/npm) :Eichel):

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

Das Entfernen dieser Lösung löste das Problem für mich.

Ausgabe von 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 

Es passiert immer noch viel (mehr als 4.500 Mal in der letzten Woche):

Stacktrace auf 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 auf Chrome Mobile:

/app-ac76ae7860adc4ef4414.js:1:179819

Semmelbrösel:

Zeit | Geben Sie | ein Fehler | Infos
- | - | - | - -
4ms vor | ANFRAGE | XMLHttpRequest-Fehler | GET /page-data/app-data.json
5ms vor | ANFRAGE | XMLHttpRequest-Fehler | GET /page-data/index/page-data.json
6ms vor | ANFRAGE | XMLHttpRequest-Fehler | GET /page-data/app-data.json
7ms vor | ANFRAGE | XMLHttpRequest-Fehler | GET /page-data/index/page-data.json
10ms vor | ANFRAGE | XMLHttpRequest-Fehler | GET /page-data/app-data.json
10ms vor | ANFRAGE | XMLHttpRequest-Fehler | GET /page-data/index/page-data.json

Die meisten davon passieren auf Mobile Safari und Chrome Mobile:

Gatsby-Version: 2.20.13

Überprüfen Sie diese Lösung.
https://github.com/gatsbyjs/gatsby/issues/11461#issuecomment -459732145

Ich benutze nicht gatsby-plugin-offline daher gibt es keine Servicemitarbeiter.

Gibt es irgendeinen Fortschritt? Ich habe ein Problem und das Plugin ist offline. Ich kann das Plugin nicht deaktivieren, um zu testen, ob Fehler auftreten.

Ich glaube nicht, dass dies etwas mit dem Offline-Plugin zu tun hat. Wir sehen viele dieser Fehler und haben sie nie benutzt.

Reproduzieren:

• Gehen Sie zu [Beispiel nicht mehr benötigt, siehe unten], notieren Sie Fehler in der Konsole und nicht funktionierende Reaktion.
• Navigieren Sie zur Startseite mit dem Logo oben links.
• Navigieren Sie zurück zur Originalseite, indem Sie in der Kopfzeile auf "Recherchieren" klicken. Seite funktioniert jetzt und Panels sind zusammenklappbar.

Wie debugge ich das? Es gibt keine Netzwerkanforderungen, die 404 oder so, also verstehe ich nicht, was passiert. Lokale Versionen sind wie folgt, aber Builds erfolgen auf 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

In unserem Fall hatten wir eine Seite als Standardexport und dann auch einen benannten Export in der Auslagerungsdatei. Sobald irgendetwas auf den benannten Export von außerhalb der Auslagerungsdatei verwies, wurde es sehr verwirrt.

Die Korrektur bestand darin, alle Exporte von den Seiten mit Ausnahme des tatsächlichen Exports der tatsächlichen Seitenkomponenten zu entfernen.

@thekevinbrown War der Fehler, den Sie sahen, zeitweise? Oder ist es jedes Mal passiert?

@Undistraction jedes Mal, wenn Sie die Seite mit dem Problem gestartet oder aktualisiert haben. Wenn Sie auf einer anderen Seite begonnen haben oder von der Seite zu einer funktionierenden Seite navigiert sind, war dies in Ordnung. Grundsätzlich schlägt die anfängliche Flüssigkeitszufuhr in diesem Fall fehl. Wenn Sie den Benutzer auf eine andere Seite bringen können, auf der die Flüssigkeitszufuhr funktioniert, funktioniert das Herunterladen und Anzeigen der defekten Seite.

Wäre definitiv besser als klarer Build-Fehler als als obskurer Laufzeitfehler gewesen, wenn das möglich wäre.

@thekevinbrown Ich denke, Ihr Problem hat nichts mit diesem Problem zu

Dieser Fehler ist auf unserer Produktseite aufgetreten und das Upgrade auf die neueste Gatsby-Version (Veröffentlichung erst vor 2 Tagen) hat den Fehler für Safari behoben

Auf die neueste Gatsby-Version aktualisiert. Problem tritt immer noch auf

Ich habe das noch nie erlebt. Plötzlich passiert es jedes Mal. Nur in Produktion 😢
Dies geschah nach einem Update vor 20 Stunden. Wir aktualisieren Abhängigkeiten ziemlich regelmäßig.
Im Grunde ist das Projekt nicht verfügbar und ich habe keine Ahnung, wie ich es wieder zum Laufen bringen kann.

Ich habe versucht, die Aktualisierungen auf den Stand vor 20 Stunden zurückzusetzen. Hat nicht geholfen.
Das Zurücksetzen auf vor 8 Tagen hat auch nicht geholfen.

Hier ist das Projekt mit neuen Updates: https://vermehrungch-4utm3ymcd.now.sh/Vermehrung/
Und hier die letzte Arbeit von vor 8 Tagen: https://vermehrungch-9l709pu84.now.sh/Vermehrung/

Wenn Sie die Gatsby-Abhängigkeiten auf das zurücksetzen, was sie vor 9 Tagen waren, funktioniert ein neuer Build wieder 😆

Ich werde jetzt versuchen zu isolieren, welche Gatsby-Abhängigkeit dies verursacht.

Ok, in unserem Fall:

• definitiv ist gatsby selbst die ursache
• Versionen bis 2.20.36 funktionieren
• v2.21.2 und v2.21.3 haben den obigen Fehler (ich hatte v2.21.17 früher getestet, der gleiche Fehler)
• v2.21.0 hat einen anderen Fehler:
  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)

Update: Der Fehler tritt weiterhin in gatsby v2.21.19 auf

@barbalex Könnten Sie Ihre Website mit uns teilen? Wenn es privat ist, senden Sie eine E-Mail an [email protected].

Ich erhalte diesen Fehler auf Ihrer Website, wenn ich ihn debugge

[].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"]);

Stacktrace:

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)

Die Seite ist:

• https://vermehrung.ch
• https://github.com/barbalex/vermehrung
• Sie können sich sogar mit dem per E-Mail gesendeten Passwort anmelden

Die Seite befindet sich in der Entwicklung. So können Sie sogar Daten bearbeiten.

In Sentry wurden immer wieder dieselben Fehlermeldungen angezeigt:

Wir verwenden die Gatsby-Version "2.21.22".

Ich bin auf dasselbe Problem gestoßen und habe es durch ein Downgrade auf Version 2.20.36 behoben, das oben erwähnt wurde.

Ok, in unserem Fall:

• definitiv ist gatsby selbst die ursache
• Versionen bis 2.20.36 funktionieren
• v2.21.2 und v2.21.3 haben den obigen Fehler (ich hatte v2.21.17 früher getestet, der gleiche Fehler)

Ich bin in einem anderen Projekt mit Version 2.21.12 erneut darauf gestoßen. Dies ist wirklich schlecht, da es nur in der Produktion auftritt. Bitte priorisieren Sie diesen Fehler.

Wir sehen dies in der Produktion auf https://www.voteamerica.com/. Es passiert hauptsächlich auf Mobile Safari, aber wir sehen es auch auf Android Chrome, Desktop Safari, Desktop Chrome und anderen. Wir verwenden derzeit Gatsby 2.21.40, aber wir haben das Problem auch am 2.20.12 gesehen

Ich habe das gleiche Problem für die eine Seite, die kürzlich gelöscht wurde. https://intergiro.com/legal zeigt die benutzerdefinierte 404-Seite nicht wie erwartet an (Desktop Chrome, Gatsby 2.20.8). Kommt auch nur in der Produktion vor.

In meinem Fall löste der Kommentar von @Kanuny indirekt mein Problem. Ich habe die JSON-Auslagerungsdaten versehentlich in eine HTML-Datei umgeleitet, als publicLoader.loadPage versuchte, sie abzurufen. Nach dem Korrigieren der Weiterleitungen werden die Seitendaten von JSON ordnungsgemäß geladen und alles funktioniert wie gewohnt.

Der Fehler verschwand plötzlich wieder. Sieht so aus, als wäre es mit dem Cache oder etwas anderem verbunden

Der Fehler tritt auch in der Version 2.22.12 unter den neuesten Versionen von Firefox und Chrome weiterhin auf.

Bitte repariere es!

Bitte repariere es!

@SoldierCorp Bitte lesen Sie, was Open Source ist, und versuchen Sie es möglicherweise selbst zu beheben.

@antoinerousseau Es geht auch darum, sich gegenseitig zu helfen, wo diejenigen, die Hilfe brauchen - darum bitten - und diejenigen, die wissen wie - sie anbieten. Ich denke, Ihr Kommentar ist fehl am Platz.

@andrzejwp Ja, es geht darum, sich gegenseitig zu helfen, nicht darum, herrische Kommentare wie "Bitte reparieren Sie es!" ohne nützliche Informationen, um das Problem tatsächlich zu beheben, während 25 Personen benachrichtigt werden, die diesem Problem folgen.

Andere haben mit detaillierten Einsichten darüber kommentiert, wie sich dies auf sie auswirkt. Dies ist erforderlich, damit die Mitwirkenden ihnen helfen und hoffentlich OSS-Probleme beheben können.

* letzte Version.

Ist nur, um Gatsby wissen zu lassen, dass immer noch mehr Menschen das Problem haben und noch nicht behoben wurden.

Es tut mir leid, wenn Sie das stört, aber ich bin ein normaler Benutzer, der das Framework verwendet und keine Zeit hat, das Problem selbst zu beheben.

In meinem Fall trat dies nur beim Präfixieren von Pfaden auf, da ich versuche, gatsby-plugin-ipfs zu verwenden (das Ausführen von gatsby build --prefix-paths && gatsby serve würde für jeden einen "Fehler / Seitenressourcen für / nicht gefunden. Nicht rendern" ergeben Seite).
Auf meiner index.jsx-Seite habe ich jedoch keine Seitenabfragen ausgeführt, aber ich hatte eine Komponente, die eine staticQuery aus dem useStaticQuery-Hook enthielt.
Wenn ich diese Komponente auskommentieren und neu erstellen würde, würde der Fehler verschwinden.
Interessanterweise würde sie, wenn ich diese Komponente dann auskommentieren und erneut erstellen würde (damit die Site wieder im Ausgangszustand ist), einwandfrei laufen und nicht auf den Fehler "Fehler / Seitenressourcen für / nicht gefunden. Reaktion nicht rendern" stoßen. Schlagen Sie vor, dass der Build-Cache etwas Wichtiges enthält?

Meine (groben) Gedanken, warum dies passieren könnte, sind:

• Probleme mit der Indexseite, die eine statische Abfrage enthält, aber keine Seitenabfrage?
• Probleme mit der Reihenfolge des Erstellungsprozesses (da das Zwischenspeichern die Ergebnisse ändern kann).
• Möglicherweise ein Problem mit run static queries oder Generating image thumbnails im Erstellungsprozess, da dies die einzigen Schritte sind, die dank des Caches übersprungen zu werden scheinen.

Ich habe versehentlich die Seitendaten JSON in eine HTML-Datei umgeleitet

Ähnliche Situation hier. Im Wesentlichen stimmte ein Nginx location Direktiven-Regex auch mit /page-data/items/page-data.json überein, wenn dies nicht der Fall sein sollte. Durch Hinzufügen eines ^ zu Beginn des regulären Ausdrucks wurde die unbeabsichtigte Übereinstimmung vermieden.

Wir sehen dies in der Produktion auf https://www.voteamerica.com/. Es passiert hauptsächlich auf Mobile Safari, aber wir sehen es auch auf Android Chrome, Desktop Safari, Desktop Chrome und anderen. Wir verwenden derzeit Gatsby 2.21.40, aber wir haben das Problem auch am 2.20.12 gesehen

Auch vor dem gleichen Problem.

Hallo Gatsby-Team, hallo alle zusammen. Wäre es möglich, die in loadPage Fehler anzugeben, die die Ursache für die verschiedenen in dieser Ausgabe aufgetretenen Fehler zu sein scheinen?

Beziehen Sie sich auf die Funktion: https://github.com/gatsbyjs/gatsby/blob/030d927cddbdc64f8d93d409a5ada7442d5e62bf/packages/gatsby/cache-dir/loader.js#L179 -L242

Nach meinem Verständnis versucht diese Funktion, app-data.json , page-data.json und dann die JS-Komponenten selbst zu laden, wodurch sie sehr anfällig für Netzwerkprobleme, Serverkonfigurationsprobleme, Entwicklungsprobleme, Konfigurationsprobleme ... ist. Durch Angabe der Fehlermeldung wäre es einfacher, die zugrunde liegenden Probleme zu beheben.

(Als Referenz: Das letzte Auftreten dieses Problems auf unserer Website war auf einen zirkulären Import zurückzuführen.)

Ich habe es erneut mit v2.23.12 versucht. Gleiches Ergebnis: https://vermehrungch-1j64x2olp.vercel.app/Vermehrung

Für uns erscheint es absolut systematisch, da jede Version über 2.20.36. Auf jeder von fünf Apps, die mit Gatsby erstellt wurden. Daher wurden wir seitdem für die Aktualisierung gesperrt.

Welches beginnt, ein bisschen ein Problem zu werden. Zum Beispiel können wir keine Bibliotheken mit Core-Js in Version 3 verwenden (https://github.com/gatsbyjs/gatsby/issues/15601). Dieses Problem wurde nun behoben - wenn wir ein Upgrade durchführen könnten.

Wenn es eine Möglichkeit gibt, mit Informationen / Tests / was auch immer zu helfen, würde ich gerne.

@barbalex Sie haben den folgenden Fehler in Ihrer App:

Wir sollten diesen Fehler auf jeden Fall zeigen. Fühlen Sie sich frei, eine PR hinzuzufügen, ich habe nicht genug Bandbreite, um diese atm zu tun.

Es scheint, dass dieses Problem in unserem Fall durch das React-Context-Menü verursacht wird, wenn diese https://github.com/vkbansal/react-contextmenu/issues/284 , das während des Erstellungsprozesses ausgelöst zu werden scheint.

@wardpeet

Fühlen Sie sich frei, eine PR hinzuzufügen, ich habe nicht genug Bandbreite, um diese atm zu tun

Tut mir leid zu sagen, ich scheine nicht genug graue Zellen dafür zu haben 😢
Vielleicht macht @ b4stien ?

Das Problem besteht weiterhin in der Version 2.23.21

Ich habe keine umfassende Lösung dafür, aber ich wollte nur, dass bekannt wird, dass ich dieses Problem heute Morgen zum ersten Mal hatte.

Und ich habe es geschafft, es zu "reparieren".

Die Site wird auf AWS über einen Anbieter namens "Cloudways" gehostet.

Als ersten Test habe ich die Site für Netlify bereitgestellt - und alles hat einwandfrei funktioniert.

Nachdem ich ein bisschen herumgegraben hatte, schien es ein serverseitiges Cache-Problem zu geben, bei dem etwas namens "Lack" verwendet wurde.

Ich habe zuerst versucht, es zu "bereinigen", und nichts ist passiert - aber das Deaktivieren und erneute Aktivieren hat funktioniert.

Diese Seite existiert seit ungefähr 18 Monaten in dieser Umgebung mit regelmäßigen Updates, und dies war das erste Mal, dass ich auf dieses Problem gestoßen bin.

Ich habe kürzlich ein Upgrade auf:
Gatsby CLI-Version: 2.12.59

Ich bin mir nicht sicher, ob dies Auswirkungen hätte haben können, aber es ist die einzige Änderung, an die ich denken kann - es sei denn, es gab natürlich eine Änderung auf der Hosting-Seite.

Hoffentlich hilft das jemandem da draußen 🤷

BEARBEITEN:

Das Problem trat innerhalb von 5 Minuten wieder auf, als ich den "Lack" -Cache wieder aktivierte.

Ich habe diese Funktion vorerst deaktiviert.

In unserem Fall funktioniert jede Seite, die aus dem Ordner /pages aber der Rest, der mit createPages nicht rehydrieren.
Dieses Problem tritt sowohl auf lokaler als auch auf CI-Ebene auf.

In unserem Fall alle Seiten, die mit createPages , da wir die Internationalisierung mit dem Präfix /${locale}/ jede Seite verwenden.

In unserem Fall alle Seiten, die mit createPages , da wir die Internationalisierung mit dem Präfix /${locale}/ jede Seite verwenden.

Hast du eine Lösung dafür gefunden? Wir haben auch dieses Setup mit vielen Gebietsschemas

@kdichev Nein, ich habe keine Lösung gefunden. Warten auf das Gatsby-Team, um dies auf Bibliotheksebene zu beheben.

Ich bin mir immer noch nicht sicher, wo das Problem liegt. Ich würde gerne eine PR dafür erstellen, würde aber gerne wissen, ob das zugrunde liegende Problem vorliegt?

Hey Leute, ich stehe vor diesem Problem bei der Produktion mit IE11.

"gatsby": "^ 2.23.11"

Außerdem wird auf allen Seiten des IE11 ein leeres Ergebnis (keine Flüssigkeitszufuhr) angezeigt.
Seitenressourcen für / nicht gefunden. Nicht rendern reagieren

Gatsby v2.24.2

BEARBEITEN: Ich habe zur vorherigen funktionierenden Version v2.22.11 zurückgekehrt. ie11 hat in diesem Commit funktioniert und zu Recht auch jetzt, allerdings nur, wenn ich package-lock.json und npm ci beibehalten habe. Irgendwie glaube ich nicht, dass dies falsch ist, also liste ich einige mögliche nachgelagerte Änderungen auf, die relevant sein könnten:
(Arbeitsversion -> fehlerhafte Build-Version)
die großen, die wahrscheinlich Kandidaten für nur ie11 Fehler sind:
@ babel / core 7.10.0 -> 7.10.5
@ core / js 2.6.11 -> 3.6.5
Gatsby-Legacy-Polyfills neue Dep 0.0.2

andere weniger wahrscheinlich:
@ graphql-tools / schema new dep 6.0.14
@ graphql-tools / utils new dep 6.0.14
und dann ging mir die geduld durch, alle rot-> alle grünen im vscode diff tool durchzusehen

Andere bemerkenswerte Dinge: Ich habe den Fehler mit gatsby build && gatsby serve -H 0.0.0.0 reproduziert, so dass alle Nebeneffekte der Serverumgebung ausgeschlossen sind.

EDIT 2: Die Build-Ausgabe des Builds fauly v2.24.2, der zuerst in meinem Beitrag gemeldet wurde, stieg von 10 MB auf 30 MB. Es hat ungefähr 20 Versionen von app- {hash} .js, 2 von commons- {hash} .js und verschiedene Anzahlen von pages.js. Es scheint nicht ganz die gleichen Dateien zu sein und sie sind so datiert, dass sie mit früheren Builds übereinstimmen. Es sieht also so aus, als hätte Gatsby Build irgendwie alle verfügbaren alten Versionen gefunden und sie in / public geworfen.

Kann jemand ein Repository freigeben?

@roffelsaurus können Sie 2.23.22 versuchen?
Für uns schlägt 2.24.2 in ci / cd-Zypressentests fehl.

Kann jemand ein Repository freigeben?

Wir können unser Repo und unsere Vars privat teilen. Wenn das für Sie in Ordnung ist, senden Sie mir bitte eine E-Mail an konstantin. [email protected] und ich werde Sie zu unserem gh einladen

@wardpeet Sie können dieses Problem in dem Repository testen, auf das ich Ihnen im Zusammenhang mit Problem Nr. 25766 Zugriff gewährt habe

In meinem Fall hing das Problem mit der Bestellung von import und der Art und Weise zusammen, wie einige Bibliotheken (nämlich react-leaflet ) in einer serverseitigen Rendering-Umgebung behandelt werden. Wir hatten ein Faltblatt-Plugin importiert, bevor das Faltblatt selbst das Problem später verursachte. Ich konnte es ziemlich schnell beheben, als ich wusste, wo ich suchen musste.

Ich glaube jedoch, dass die Fehlermeldung ( page resources for / not found. Not rendering React ) unglaublich verwirrend war und das Fehlen von Details und anderen Fehlern das Hauptproblem war, da ich ziemlich tief graben musste, um zu wissen, was es überhaupt bedeutet.

An alle anderen, die dieses Problem haben: Wie habe ich es gefunden? Gutes altes Breakpointing und Debuggen in Chrom. gatsby build && gatsby serve darf die Produktionsumgebung lokal mit allen vorhandenen Quellkarten anzeigen. Ich konnte debuggen, welcher Block und dann die Komponente nicht geladen werden kann und mit Importen darin herumspielen kann. Es war ein ziemlich langsamer Prozess, seien Sie also geduldig, da Sie die Seite immer wieder neu laden werden. Suchen Sie nach Ihrem Blocknamen (in meinem Fall war es component---src-pages-index-js ) und dem ihm zugewiesenen Import. Treten Sie ein und beobachten Sie die Abhängigkeiten, da eine davon fehlschlägt. Ich glaube, dass es in jedem Fall anders sein wird, deshalb kann man nirgendwo eine gute Lösung finden. Quellkarten waren praktisch, da sie mir mehr als nur eine Reihe allgemeiner Versprechen im Array zeigten.

Dies ist nicht der Kern des Themas, aber ich werde Details darüber hinterlassen, was ich unten herausgefunden habe. Beachten Sie jedoch, dass das Folgende nur für die Reaktionsbroschüre gilt und Ihre Laufleistung variiert:

So war es also ursprünglich:

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

und so sieht es jetzt aus:

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

Das ist natürlich ein Fehler von unserer Seite, da jedes Plugin normalerweise nach der Bibliothek kommen sollte, in die es eingesteckt ist. Da react-leaflet (glaube ich) die Ladereihenfolge beim Ausführen des Debugs ein wenig ändert, war das Problem während der Entwicklung nicht sichtbar.

Ich habe gerade Uncaught (in promise) Error: page resources for /app/ not found. Not rendering React in meiner App getestet. In meinem Fall ist / app / eine Nur-Client-Route, die eine Reaktions-App enthält. Ich hatte keine Probleme mit gatsby develop , aber ich habe diesen Fehler beim Ausführen von gatsby serve und auch beim Produktions-Build erhalten. Es wurden keine Buildfehler gemeldet.

Es stellte sich heraus, dass die Probleme mit dem React-Context-Menü (https://github.com/vkbansal/react-contextmenu/issues/284) auftraten, auf das

@rgembalik , die Art und Weise, wie ich dies einzeln wieder hinzuzufügen, bis ich die Komponente fand, die den Build brach.

Für mich kann ich nicht einmal replizieren, ich sehe nur viele dieser Fehler in der Wachfehlerberichterstattung. Also nicht sicher, wie ich es herausfinden werde

Wir bekommen viele davon in Sentry mit diesen Fehlern auch für alle Arten von Seiten außer nur "/", die ebenfalls nicht repliziert werden konnten. Auf Netlify gehostet. Ich vermute, dass es etwas mit aktiven Sitzungen während der Bereitstellung zu tun hat, aber schwer zu überprüfen.

@wardpeet scheint viele verschiedene mögliche Ursachen zu haben, die denselben Fehler auslösen. Für uns sehen wir diese Fehler nur in unserem Sentry-Protokoll und konnten sie nie reproduzieren. Wäre es möglich, mehr Informationen in den Fehler aufzunehmen oder mehrere detailliertere Fehler hinzuzufügen, damit wir alle etwas mehr zu tun haben, um die Ursache zu ermitteln?

Ich habe gerade diesen Fehler auf https://www.gatsbyjs.com/ erhalten und am Ende eine leere Seite erhalten

Ich kann bestätigen, dass ich beim ersten Laden der ersten Seite diesen Fehler auf gatsbyjs.com gesehen habe

Ich habe herausgefunden, dass Gatsby eine bestimmte Art hat, die URL-Pfade mit nachgestellten Schrägstrichen zu behandeln. Ich weiß nicht, ob das helfen kann

Ich habe auch dieses Problem.

Ich kann das Repository nicht freigeben, aber wenn Sie auf diese Seite zugreifen, wird angezeigt, dass eine SVG-Datei korrekt geladen wird. Wenn ich jedoch zu einer Route gehe, die nicht existiert, z. B. https://rocketseat.com.br/test , wird eine veraltete Version des Codes angezeigt (der anstelle einer SVG weiterhin gatsby-image verwendet) und angezeigt mir diese Nachricht auf der Konsole:

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

Ich benutze [email protected]

_edit: Ich weiß nicht warum, aber nachdem ich mein Problem hier hinzugefügt habe, wurde das Image-Problem behoben, aber ich erhalte weiterhin den gleichen Fehler auf der Seitenkonsole_

Es ist schwer für mich zu replizieren, ich sehe nur eine Menge dieser Fehler in der Wachfehlerberichterstattung

@theskillwithin - das gleiche. Tausende davon in Sentry.

Ich habe das gleiche Problem. Sehr eigenartig. Es sieht so aus, als ob es verschiedene Ursachen gibt, die diesen Fehler auslösen.

Wir sehen diesen Fehler auch in verschiedenen Browsern und auf verschiedenen Seiten. Ich kann unsere Situation anscheinend nicht mit einer der oben genannten möglichen Ursachen in Verbindung bringen. Außerdem kann ich mich in der Entwicklung scheinbar nicht replizieren - dies passiert nur auf unserer bereitgestellten Website.

Ich habe das gleiche Problem. nicht in der Lage zu replizieren, aber Tonnen dieser Fehler im Wachposten. auch eine Vielzahl von Browsern
gatsby version 2.24.3

Diese werden nur selten in einer Produktionsstätte gemeldet, in der ich auch Sentry verwende. Ich kann mich nicht replizieren. So wie ich das sehe, brauchen wir eine bessere Berichterstattung. Das Seltsame daran ist, dass es tatsächlich die Seitendaten findet:

Da es einen 200-Status und AFAICT erhält, ist der JSON nicht fehlerhaft. Ich gehe davon aus, dass fetchPageDataJson() eine Erfolgsantwort zurückgibt:
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L137 -L151

Da so viel erfolgreich zu sein scheint, würde der nächste Fehlerpunkt, den ich sehen kann, das Laden der Komponente selbst sein:
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

Vielleicht gibt es ein Problem in den async-requires , die ausgeschrieben werden. Ich stelle mir jedoch vor, dass diese tatsächlich in Ordnung sind, da sie von Webpack behandelt werden und das Problem zeitweise auftritt. Wenn es ein Problem mit der Art und Weise gibt, wie diese Datei geschrieben wird, würde dies dazu führen, dass der Build bombardiert wird.

Wenn dies irgendwo in dem zu importierenden Modul ein Syntaxproblem wäre, dann stelle ich mir vor, dass es 100% der Zeit fehlschlagen würde. Möglicherweise wird in einem Modul etwas verwendet, das nicht mit dem Gerät / Browser kompatibel ist, das das Modul lädt. Sicher schwer zu sagen, da der spezifische Fehler verdeckt wird.

Was ich denke, wir brauchen den Komponentenlader, um den generierten Fehler nicht zu essen.

Wenn Promise.resolve() dort ist, wenn in asyncRequires kein Block vorhanden ist, bedeutet dies, dass der ausgelöste Fehler sinnvoll wäre. Dieser Fehler würde auch bei jedem einzelnen Besuch dieser Seite auftreten ... so wäre es einfach, die Ursache aufzuspüren.

Die Rückgabe von null im catch-Block bedeutet, dass der ausgelöste Fehler keinen Sinn ergibt. Das Modul wurde gefunden, aber beim dynamischen Import ist ein Fehler aufgetreten. Gibt das Webpack keinen Fehler im Block catch() eines dynamischen Imports zurück? Wenn dies nicht der Fall ist, ist dies möglicherweise ein Problem, das mit Webpack behoben werden sollte. Ich weiß, dass, wenn ich ein schlechtes import() von devtools aus starte, ein Fehler gemeldet wird ... ob ein Fehler gemeldet wird, basierend auf der Unfähigkeit / dem Versagen, das importierte Javascript zu analysieren, ist eine andere Frage und würde es beantworten Einige zusätzliche Tests mit Code, den ich kenne, funktionieren in bestimmten Browsern nicht.

@wardpeet erwähnt Sie bessere Fehlerberichterstattung zuvor . Ist das in Arbeit oder wird Hilfe benötigt?

In Bezug auf die Browserkompatibilität sehe ich diese Fehler hauptsächlich auf Mobilgeräten.

Aber ich habe auch gesehen, dass diese Fehler unter MacOS X mit Safari und Windows 10 mit Chrome generiert wurden.

Eine Gemeinsamkeit ist, dass der Verkehr im Allgemeinen von Facebook oder Google zu stammen scheint. Aber das kann nur Zufall sein, denn das ist es, was den größten Teil unseres Verkehrs antreibt.

_HINWEIS: Diese Site, mit der ich arbeite, verwendet tatsächlich [email protected] . Der Code, mit dem ich verlinkt habe, befindet sich an verschiedenen Stellen, aber die Logik selbst scheint sich nicht geändert zu haben. Es macht immer noch dasselbe und die potenziellen Fehlerquellen, die ich identifiziert habe, scheinen dieselben zu sein.

[email protected]

Ich sehe den Fehler auch selten auf Bugsnag. Unklar, ob die Seite für mich gerendert wird oder nicht. Hier ist der Stack auf Bugsnag, wenn er von Nutzen ist. @Pwardetet Interessant, dass er in diesem Fall mehrmals wiederholt wurde. Beachten Sie, dass dies eine von vielen / webinar / blah ... -Seiten ist, auf denen wir createPage () verwenden, aber natürlich funktioniert es für mich, wenn ich versuche, / page-data / ... wie auf dem Foto gezeigt abzurufen.

Ich werde dem protokollierten Fehler einige zusätzliche Informationen hinzufügen, damit wir das Problem hoffentlich finden können

Ich habe das gleiche Problem mit einer Seite, die einen anderen Fehler verursacht hat, der unter https://github.com/gatsbyjs/gatsby/issues/26706 veröffentlicht wurde

In meinem Fall geschieht dies in (mindestens) Desktop-Chrome und nur beim ersten Laden der Seite. Wenn ich auf Aktualisieren drücke, wird alles wie erwartet gerendert

Wenn ich dann versuche, dieses erste Mal zu replizieren, selbst im incognito -Modus und versuche, jeden Cache zu löschen, den ich mir vorstellen kann, kann ich es nicht (manchmal war ich in der Lage, aber sehr zufällig), bis nach einer Weile ( einige Tage) Ich besuche die URL und finde den gleichen Fehler (der nach erneuter Aktualisierung verschwindet)

Wenn ich versuche, es mit demselben minimalen Repo zu replizieren, das ich für das oben verlinkte Problem verwendet habe, kann ich nicht dieselben Fehler sehen (zumindest nicht die Zeiten, die ich jetzt versucht habe).

Der Fehler ist (in diesem Fall) sichtbar, weil das Mauerwerksgitter nicht erstellt wird. In meinem Fall wird die Seite zerstört, es sei denn, der Benutzer denkt darüber nach, die Seite zu aktualisieren (ich vermute, dass dies nicht der Fall ist).

Eigentlich fühlt es sich so zufällig an, dass ich es seit ein paar Wochen sehe, aber ich habe immer gedacht, dass dies etwas mit meinem PC ist

Ich habe npm auidit fix und das Problem wurde für mich behoben.

Folgen! Habe das gleiche Problem auch

Hallo,

Wir haben dieses Problem auch nur in der Produktion. Wir reproduzieren diesen Fehler 100% der Zeit bestimmter URLs. Sehen wir uns die Baumstruktur unseres Verzeichnisses public :

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

Wenn wir diese URLs https://domain.com/usages/brainstorming eingeben, funktioniert es perfekt, https://domain.com/usages/seminaries auch. Wenn wir eine unbekannte URL wie https://domain.com/doesnotexist eingeben, haben wir zu Recht die 404-Seite, aber wenn wir versuchen, eine URL zu erreichen, die mit einem tatsächlichen Ordner im Baum übereinstimmt, wie https://domain.com/usages , haben wir diese leere Seite und dieser Fehler.

Läutet das vielleicht eine Glocke für Sie?

Beste

@guillaumepotier wirst du auch Nginx verwenden?

Ich denke, es könnte durch fehlerhafte Antwortheader verursacht werden.

@ daydream05 ja in der Tat verwenden wir Nginx. Wir haben in unseren Protokollen 304 nicht geänderte Inhaltsheader und manchmal 200 Antworten gesehen.

mit AWS S3 Bucket

Gleiches gilt hier für das Hosting in AWS S3 (mit CloudFront CDN).

Ich habe npm audit fix und das Problem wurde für mich behoben.

Interessant @ liuuuk311. Ich habe es bei unserem Projekt versucht und möglicherweise hat es das Problem auch für uns gelöst. Die Zeit wird es zeigen, aber bis jetzt nach 48 Stunden gibt es keine Vorkommen in unseren Protokollen.

Edit: 5 Tage später, noch keine Vorkommen ...

Bearbeiten: 10 Tage später und es ist ein paar Mal wieder aufgetreten, sorry zu melden. Das Ausführen von npm audit fix an sich scheint das Problem nicht zu lösen.

@wardpeet einige zusätzliche Bugsnag-Daten, die bei der Diagnose helfen können ...

Demnach sieht es so aus, als würden page-data.json-Dateien tatsächlich korrekt geladen ...

• da ich heute darauf gestoßen bin, werde ich hier stoßen und zuschauen.

In meinem Fall habe ich das Problem beim Laden von polyfill.io lib auf die Seite behoben

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

@pedrofsantoscom Bitte erläutern Sie, wie statisch geladenes Skript ein Problem für gatsby.js löst.

Hatte gestern das gleiche Problem. Durch das lokale Löschen des Caches wurde dies für den aktuellen Benutzer behoben. Also haben wir den Cache bei Cloudflare geleert und jetzt bekommen wir keine Berichte mehr.
Das Löschen des Cache war unsere Lösung

Wir verwenden Cloudflare nicht, wir verwenden AWS Cloudfront CDN und es wird nach jeder Bereitstellung ungültig. Ich hatte den Fehler lokal festgestellt, indem ich einen lokalen Webserver mit https ausgeführt habe, wobei der erste Versuch nach dem Start des Webservers ausgeführt wurde und auch einige nachfolgende Seiten neu geladen wurden, jedoch nicht jedes Mal. Ich sehe kein Muster. Es passiert nur ab und zu.

Wir verwenden Cloudflare nicht, wir verwenden AWS Cloudfront CDN und es wird nach jeder Bereitstellung ungültig. Ich hatte den Fehler lokal festgestellt, indem ich einen lokalen Webserver mit https ausgeführt habe, wobei der erste Versuch nach dem Start des Webservers ausgeführt wurde und auch einige nachfolgende Seiten neu geladen wurden, jedoch nicht jedes Mal. Ich sehe kein Muster. Es passiert nur ab und zu.

Das war die Lösung für uns. Als wir den Cache geleert haben, haben sich die Fehler pro Stunde schnell verringert und wir haben zumindest im Bugsnag nicht den gleichen Fehler erhalten. Dies ist in der Tat ein seltsamer Fehler.

Ich hatte die gleiche Fehlermeldung, aber nur in Internet Explorer. Alle anderen Browser haben diese Art von Fehlermeldung nicht angezeigt.

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

Ich habe das Problem auf einen Import zurückgeführt, den ich in meine Reaktionskomponenten vorgenommen habe. In einigen Fällen hatte ich Abhängigkeiten zu https://sap.github.io/ui5-webcomponents/ . Nachdem ich diese Abhängigkeiten entfernt hatte, verschwand das Problem. Ich kann nicht erklären, was die eigentliche Grundursache ist, möchte aber darauf hinweisen, dass Abhängigkeiten in Ihren Reaktionskontrollen dieses Problem verursachen können.

@Chaosbohne kann damit nicht wirklich streiten, aber ich würde sogar sagen, dass es sich um gatsby.js -Team um das Abhängigkeitsmanagement und die Sicherheit und entfernt im ersten Schritt ^ aus allen Abhängigkeits- / devDependency-Versionen. Eine ganze Reihe von Problemen könnte verhindert werden.

Ich kann sagen, dass dieses Problem nicht browserabhängig ist. Ich habe es in Chrome und Safari basierend auf Sentry-Protokollen und in Chrome 85, 86 lokal auf meinem Mac gesehen.

Keine der Lösungen funktioniert. @KyleAMathews Aufgrund dieses Problems verlieren wir das Geschäft. Innerhalb von 3-4 Tagen tritt dieses Problem auf und wir können die Hauptursache nicht herausfinden. Bitte helfen Sie uns, die Lösung für dieses Problem zu finden.

@ R3coN haben Sie versucht, Ihre Website neu zu

@ R3coN, wenn es helfen kann, hier sind die Paketversionen, die wir verwenden und die gut funktionieren:

    "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 Ja, das ist die einzige Möglichkeit, das Gatsby CLI-Version: 2.12.67 und die Gatsby-Version: 2.24.47. Wie Sie bereits erwähnt haben, funktioniert die Version 2.20.36 von Gatsby einwandfrei. Wir werden unser Glück versuchen, indem wir die Gatsby-Version herabstufen.

@ shide1989 Danke für den Kommentar. Aber ein Downgrade der Version wirft mir diesen Fehler ->

WebpackError: Das Ergebnis dieser StaticQuery konnte nicht abgerufen werden.

Welches funktionierte in der vorherigen Version 2.24.47.

Es tut mir leid, das zu hören. Möglicherweise fehlt Ihnen ein mit graphql markiertes Vorlagenliteral in derselben Datei, in der der useStaticQuery-Hook zum Extrahieren von Abfragen zur Erstellungszeit verwendet wird. (wie hier beschrieben: https://github.com/gatsbyjs/gatsby/issues/24526)

trotzdem viel glück damit

Aber ich habe dir gesagt, dass der gleiche Code für gatsby 2.24.47 funktioniert.

@ R3coN Dieses Problem kann auch durch falsches statisches Caching verursacht werden. Wenn Sie nginx oder s3 für Ihren Server verwenden und Ihre page-data.json nicht ungültig machen, werden Ihre StaticQueries bei jeder Änderung Ihrer Daten unterbrochen.

Ich hatte dieses Problem und es stellte sich heraus, dass ich alle page-data.json zwischengespeichert habe. Sie sollten nicht sein. Sie müssen bei jeder Anfrage erneut validiert werden

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

@ daydream05 Danke für den Kommentar. Ja, ich verwende S3 mit CloudFront. Haben Sie eine Idee, wie Sie dies mit Cloudfront erreichen können?

@ daydream05 Ich habe bereits eine Cache-Kontrolle: 'public, max-age = 0, must-revalidate' wurde zu page-data.json und app-data.json hinzugefügt, was bedeutet, dass diese Seiten nicht zwischengespeichert werden.

Ich sehe dies auch auf Seiten, die nicht existieren (die die 404-Seite laden und mit Feuchtigkeit versorgen sollten).

Vor Ort funktionieren meine Entwickler- und Produktions-Builds ohne diesen Fehler. Wenn ich während der Prüfung ein console.log einfüge, das diesen Fehler in der erstellten Produktion app-[hash].js , kann ich sehen, dass page Objekt existiert und enthält page.componentChunkName: ""component---src-pages-404-js" wie ich es erwartet habe.

Wenn die App jedoch in der Gatsby Cloud bereitgestellt wird, tritt der Fehler bei jedem Laden einer nicht vorhandenen Seite auf. Die SSR'd 404-Seite wird im Browser angezeigt, aber dann wird der Fehler ausgegeben, sodass React niemals im Browser ausgeführt wird. Wenn die 404-Seite direkt geladen wird (indem Sie den Pfad /404 besuchen), funktioniert sie einwandfrei und ohne Fehler.

Dies ist schwer zu diagnostizieren, da ich es bisher nicht lokal replizieren konnte.

Verwenden der neuesten Version: "gatsby": "^2.24.91"

Veröffentlichen Sie dies einfach hier, damit andere Benutzer react-md , um ihre Website schnell zu reparieren, oder hoffen Sie, dass dies trotzdem dazu beitragen kann, dieses Problem in Gatsby zu beheben.

Ich hatte den gleichen Fehler in einem meiner Projekte, in denen ich react-md
Nachdem ich alle Komponenten entfernt hatte, konnte ich das Problem beseitigen.

Da ich jedes Mal ein Prod bereitstellen musste, um dies zu testen, habe ich es nicht geschafft, genau zu bestimmen, bei welcher bestimmten Komponente dieses Problem auftritt, aber ich habe es eingegrenzt.

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";

Ich werde meinen Blog-Beitrag zu diesem Thema aktualisieren, wenn ich Zeit habe, tiefer zu graben.

In Bezug auf 404 Seiten kann ich das Problem von @aMoniker bestätigen, da für mich dasselbe Verhaltensmuster

Vor Ort funktionieren sowohl Entwicklungs- als auch Produktions-Builds einwandfrei mit der Seite 404 Bei der Bereitstellung in Gatsby Cloud tritt das Problem jedoch auf jeder unbekannten Seite mit Ausnahme des tatsächlichen Pfads /404 .

Ich habe diesen Fehler auch festgestellt und durch Löschen des Browser-Cache behoben. Es wäre jedoch gut, eine Lösung zu finden, die dies nicht erfordert, da wir nicht alle unsere Anwendungen dazu zwingen können.

@ dejavu1987 Wir verwenden react-md nicht für Projekte, bei denen dieses Problem

@MaciekBaron Ich hatte einen Fehler lokal reproduziert, geleert und die Seite nach jedem Löschen neu

Dies scheint ein Caching-Problem zu sein, wie ich bereits erwähnt habe. Wenn Ihre Cache-Header alle richtig eingestellt sind, liegt das Problem möglicherweise bei den Servicemitarbeitern.

Vielleicht probieren Sie dieses Plugin aus?
https://www.npmjs.com/package/gatsby-plugin-remove-serviceworker

Hey, ich stoße auch auf dieses Problem. In der Entwicklung funktioniert alles einwandfrei, aber wenn ich gatsby build ausführe und das öffentliche Verzeichnis auf meinem Webhoster bereitstelle, funktioniert eine Seite aufgrund dieser Fehlermeldung nicht.

Ich war sehr neugierig und schaute in das öffentliche Seitendatenverzeichnis. Ich habe festgestellt, dass das spezifische Seitenverzeichnis vorhanden ist, aber nicht in Kleinbuchstaben, sondern in Großbuchstaben. Das war das Problem, bei dem ich die Fehlermeldung erhalten habe.

Danach habe ich es am Anfang in einen kleinen Buchstaben geändert und es funktioniert gut in Prod. Ich denke, dies tritt auf, weil ich den Namen der Seite früher geändert habe und vielleicht wird hier etwas zwischengespeichert?

Ich stoße auch auf dieses Problem. Ich habe eine Methode gefunden, um dieses Problem zu beheben. Aber ich denke, es hat das wahre Problem nicht behoben.

Lassen Sie mich nun erklären, wie das Problem behoben werden kann.

Dieses Problem wurde in der Test- oder Produktionsumgebung festgestellt. Wie oben erwähnt, wird es in der Entwicklung nicht reproduziert. Selbst im Test oder in der Produktion trat dies nicht jedes Mal auf. Und ich fand heraus, dass alle Skripte vorinstalliert und asynchron ausgeführt wurden. Ich denke, es kann durch die ausführende Reihenfolge der Skripte verursacht werden.

Während ich das Netzwerk im Netzwerk verlangsame, z. B. 3G fast , trat das Problem fast jedes Mal auf. Dies bestätigte meine Vermutung.

Um meine Vermutung zu bestätigen, habe ich den Prozess des Renderns von HTML in gatsby-ssr.js geändert, um alle Skripte ohne "asynchron" wie folgt

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

Zum Glück funktioniert es.

Obwohl dieser Weg zur Behebung des Problems beitragen kann, halte ich dies nicht für einen guten Weg. Es scheint, als würde man die Funktion von Gatsby verletzen. Wird das Skript so asynchron ausgeführt, dass es so aussieht?

Hoffentlich können Sie auf diese Weise auch alle Ihre Probleme lösen.

Dieses Problem wurde in der Test- oder Produktionsumgebung festgestellt. Wie oben erwähnt, wird es in der Entwicklung nicht reproduziert. Selbst im Test oder in der Produktion trat dies nicht jedes Mal auf. Und ich fand heraus, dass alle Skripte vorinstalliert und asynchron ausgeführt wurden. Ich denke, es kann durch die ausführende Reihenfolge der Skripte verursacht werden.

Obwohl dieser Weg zur Behebung des Problems beitragen kann, halte ich dies nicht für einen guten Weg. Es scheint, als würde man die Funktion von Gatsby verletzen. Wird das Skript so asynchron ausgeführt, dass es so aussieht?

Ich denke, Sie haben Recht, ich hatte dieses Problem aus seltsamen Gründen wieder.
Das letzte war wild, aber wenn ich es mit Ihrer Antwort verbinde, macht es Sinn.

Vor kurzem habe ich meiner Layoutkomponente eine Schriftart-Symbolkomponente hinzugefügt, die dieses Problem reproduziert.
Ein wichtiger Punkt ist, dass die Schriftsymbole die ganze Zeit in anderen tief verschachtelten Komponenten verwendet wurden und das Problem nie verursacht haben, nur wenn es sich auf der Layoutebene befindet, der ersten Komponente, die von einer Seitenkomponente aufgerufen wird.

Ich könnte mich irren, aber dies könnte ein gutes Szenario sein, um die tatsächliche Ursache herauszufinden.

@ dejavu1987 Stimme dir zu. Vielleicht haben Sie ein gutes Szenario angegeben, um die tatsächliche Ursache herauszufinden.

Außerdem frage ich mich, ob es geeignet ist, die Skripte mit async zu laden und auszuführen, da das Webpack Codes in verschiedene Chunks aufteilt, die Chunks jedoch möglicherweise Abhängigkeiten aufweisen.

Das Hauptproblem scheint zu sein, dass Gatsby Fehler beim Laden der Seite verschluckt und nur die sehr allgemeine Meldung page resources for / not found. Not rendering React meldet, weshalb in diesem Thread so viele verschiedene mögliche Ursachen gemeldet werden.

Mein Problem stellte sich heraus, dass Mobx 5 IE11 nicht unterstützt, und obwohl Mobx eine nette Fehlermeldung dafür bereitstellt, bekam ich nur die Meldung "Seitenressourcen nicht gefunden" von Gatsby, die ziemlich irreführend war.

Ich würde demütig als Lösung für dieses Problem vorschlagen, die ursprüngliche Fehlermeldung zu melden, die dazu geführt hat, dass das Laden der Seite fehlgeschlagen ist. @wardpeet

Was es für mich behoben hat, ist, dass ich S3 so eingerichtet habe, dass es eine 200 auf der 404-Seite zurückgibt. Als ich es geändert habe, um einen 404-Statuscode zurückzugeben, hat es funktioniert.

Ja, das habe ich auch gefunden. Mein Problem war jedoch umfassender… Ich habe die Cloudfront 404-Ergebnisse nicht ordnungsgemäß zwischengespeichert. Der Grund, warum ich zwischen Cloudfront und S3 404 Ergebnisse erhalten habe, ist, dass die Bereitstellung in S3 über CodePipeline meines Erachtens die Build Artifact ZIP-Datei entpackt - aber nicht in einer bestimmten Reihenfolge. Für einige Minuten können neue HTML-Dateien auf neue JS-Dateien (mit neuen Hashes) verweisen, die noch nicht vorhanden sind. Unabhängig davon, was das Caching für Ihre gehashten Asset-Dateien handhabt, dürfen 404-Ergebnisse nicht zwischengespeichert werden, da dies nur durch Leeren des CDN-Cache korrigiert werden kann.

Hat jemand herausgefunden, wie man sicherstellt, dass HTML-Dateien zuletzt in S3 bereitgestellt werden?

David
https://ewebinar.com

Am 21. Oktober 2020 um 12:40 Uhr schrieb Vince P. [email protected] :

@ R3coN https://github.com/R3coN Dieses Problem kann auch durch falsches statisches Caching verursacht werden. Wenn Sie nginx oder s3 für Ihren Server verwenden und Ihre page-data.json nicht ungültig machen, werden Ihre StaticQueries bei jeder Änderung Ihrer Daten unterbrochen.

Ich hatte dieses Problem und es stellte sich heraus, dass ich alle page-data.json zwischengespeichert habe. Sie sollten nicht sein. Sie müssen bei jeder Anfrage erneut validiert werden

https://www.gatsbyjs.com/docs/caching/ https://www.gatsbyjs.com/docs/caching/
- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, sehen Sie sie auf GitHub https://github.com/gatsbyjs/gatsby/issues/19618#issuecomment-713298516 an oder melden Sie sich ab https://github.com/notifications/unsubscribe-auth/AA3SHT55MXZTXQUAXH5ZUY3SLZ4QLQM4 .

Ich kann hinzufügen, dass ich ein Problem mit Chrome Lighthouse Audit bei mobilen Tests, mit und ohne PWA-Tests reproduziert habe. Ich bin mir sicher, dass mobile Tests Netzwerk- und CPU-Grenzwerte verwenden, sodass asynchrone Skripte, die nicht in der richtigen Reihenfolge geladen werden, oder eines von 30 fehlgeschlagenen Skripten häufig vorkommen kann.

Ich arbeite mit 3D und selbst bei localhost mit webpack und gatsby.js führt das Neuladen der Seite ziemlich oft zu fehlgeschlagenen Netzwerkanforderungen für das statische Modell gtlf Dateien. Eine davon ist fehlgeschlagen - die gesamte App ist fehlerhaft (wenn keine Fehlergrenze festgelegt ist).

Ich denke, hier könnte das gleiche Muster sein, aber ohne ordnungsgemäße Fehlerbehandlung.

Ich verwende S3 und CloudFront für die Produktion. Ich hatte ein ähnliches Problem, aber in meinem Fall wurde nur in Cloudfront ein Can't render React -Fehler in der Konsole angezeigt. Dies begann nach dem Ändern von Dateien in der Produktion S3. Zu meiner Überraschung wurde das Problem gelöst, nachdem der Leuchtturm für den Produktionsursprung erneut ausgeführt wurde.

Dies geschah nur auf meinem Gerät im normalen Modus. In meinem Fall hat das Bereinigen des gesamten Caches, der Cookies, des lokalen Speichers, des Sitzungsspeichers und der Servicemitarbeiter früher nicht geholfen.

Wenn Sie also Ihren Produktionsursprung mit Leuchtturm profilieren und Dateien geändert wurden, kann dieses Problem ebenfalls auftreten (in meinem Fall war es)

Mein Punkt ist, dass ich es mit Leuchtturm so ziemlich 1 von 10 reproduzieren kann, und der letzte Einsatz war lange her.

Ich glaube nicht, dass Gatsby dieses Problem lösen kann, weil dies jedem passiert, aber der Grund ist anders. Ich bekomme zu oft leere Seiten oder wenn ich etwas in der Backend-Gatsby-Seite ändere, wird es leer und wirft einen Fehler aus, und auch dieser Fehler ist jedes Mal anders. Ich denke, wir müssen aufhören, Gatsby zu verwenden und zu einem anderen zuverlässigen Framework wechseln.

Ich könnte den Fehler beheben, wenn es eine Möglichkeit gibt, ihn zu reproduzieren, aber es gibt keine. Dieser Fehler tritt zufällig auf, manchmal einen Tag nach der Bereitstellung, manchmal 3-4 Tage nach der Bereitstellung. Aber es passiert.

@antoinerousseau Hast du etwas gefunden? Kann mir jemand Schritt für Schritt sagen, wie ich dieses Problem zumindest beheben kann? Ich habe alle Dinge von meiner Seite aus versucht, aber 1-2 Tage nach der Bereitstellung der Website bricht. Kann mir jemand sagen, wie ich wissen soll, wann dieses Problem auftreten wird, weil es für mich zu zufällig auftritt?

Was es für mich behoben hat, ist, dass ich S3 so eingerichtet habe, dass es eine 200 auf der 404-Seite zurückgibt. Als ich es geändert habe, um einen 404-Statuscode zurückzugeben, hat es funktioniert.

S3 oder Cloudfront?

In meinem Fall lag das Problem auf einer 404-Seite, die standardmäßig von Azure verwendet wurde. Es war ein Blockierungsfehler und das einzige, was ich in der Konsole sehen konnte, war
Error / page resources for / not found. Not rendering React

Seit ich angefangen habe, benutzerdefinierte 404 zu verwenden - Problem weg.

Ich bekomme das gleiche, wenn ich die App auf Netlify bereitstelle. Lokal funktioniert Gatsy Build und Gatsby Serve gut. Dies ist noch seltsamer.

@atapas können Sie sich bitte an den Netlify-Support wenden? Vielleicht können sie etwas von ihrer Seite klären?

@atapas können Sie sich bitte an den Netlify-Support wenden? Vielleicht können sie etwas von ihrer Seite klären?

Ja, habe ich. Vielen Dank!

Vielleicht wäre hier eine bessere Stapelverfolgung oder eine eindeutige Fehlermeldung hilfreich. Trotzdem danke für die Antwort.

@atapas Ich bin kein Mitglied eines Teams und habe nur den gleichen Fehler wie Sie.

Ich bekomme das gleiche, wenn ich die App auf Netlify bereitstelle. Lokal funktioniert Gatsy Build und Gatsby Serve gut. Dies ist noch seltsamer.

Ich habe die Lösung in einem völlig anderen Kontext gefunden. Ich habe den Fehler erhalten, weil Netlify die env-Variablen ignoriert hat, die ich festgelegt habe, damit Auth0 in meiner App funktioniert.

Domäne: process.env.AUTH0_DOMAIN,
clientID: process.env.AUTH0_CLIENTID,
redirectUri: process.env.AUTH0_CALLBACK,

Ich habe später von hier aus über "Bereitstellen ohne vertrauliche Variablen" gelesen und es behoben, wie es im Dokument erwähnt wurde.

Ich bin überrascht von dem Fehler, den ich bekommen habe und in dem die Lösung gelandet ist. Aber ich bin froh, dass es funktioniert hat.

@atapas Ich bin kein Mitglied eines Teams und habe nur den gleichen Fehler wie Sie.

@ JustFly1984 , Keine Sorge, ich wollte mich wirklich bei dir

Ich bekomme das nur in Chrome. Safari funktioniert super. Ich habe gerade die Offline- und Manifest-Plugins zu meinem Projekt hinzugefügt. Ich kann es nicht mit Gatsby develop oder mit gatsby build & gatsby serve lokal reproduzieren. Ich hoste auf Netlify.

Für mich verursachte dieser Codeblock außerhalb meiner React-Komponente sowie das Verweisen auf die globalen Variablen in der React-Komponente den Fehler. Durch Entfernen wurde das Problem behoben.

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)
  );
}