Gatsby: Fehlende Ressourcen für /

Könnte mit https://github.com/gatsbyjs/gatsby/issues/11453 zusammenhängen

Vielleicht, obwohl es hier keine 404 Sachen gibt.

Tut mir leid, dass du das siehst ,

Könnten Sie bitte wenn möglich auf eine minimale Reproduktion verweisen?

Ich konnte nicht lokal reproduzieren. 🙁 Gibt es weitere Informationen, die ich Ihnen geben kann, oder hilft der Wachbericht überhaupt? Unter welchen Umständen könnte dies auftreten, damit ich es eingrenzen kann?

Ich sehe dies auch, aber erst nach der Bereitstellung kann ich nicht lokal reproduzieren.

Uncaught Error: Missing resources for /store/
    at t.n.render (ensure-resources.js:135)
    at Xo (react-dom.production.min.js:156)
    at Qo (react-dom.production.min.js:155)
    at ti (react-dom.production.min.js:162)
    at Oi (react-dom.production.min.js:192)
    at ji (react-dom.production.min.js:193)
    at fa (react-dom.production.min.js:205)
    at sa (react-dom.production.min.js:204)
    at Mi (react-dom.production.min.js:200)
    at ya (react-dom.production.min.js:218)

Ich habe jedoch festgestellt, dass ich diesen Fehler nur in einem Zweig erhalte, in dem ich versucht habe, ThemeProvider (gestaltete Komponenten) aus meinem Code zu entfernen, und ich vermute, dass irgendwo in der Dateistruktur etwas durcheinander geraten ist, da keine Pakete hinzugefügt / aktualisiert / entfernt wurden. Wird aktualisiert, wenn ich die Ursache herausfinde, aber es gibt nicht viel zu tun.

Ich habe das gleiche Problem hier ... zuerst, entschuldige mein Englisch, ich spreche Spanisch ¯_ (ツ) _ / ¯

Error: Missing resources for /...
    at t.n.render (ensure-resources.js:135)
    at Ri (react-dom.production.min.js:169)
    at Ci (react-dom.production.min.js:168)
    at Li (react-dom.production.min.js:176)
    at Ba (react-dom.production.min.js:221)
    at Ha (react-dom.production.min.js:222)
    at Pl (react-dom.production.min.js:238)
    at Tl (react-dom.production.min.js:237)
    at wl (react-dom.production.min.js:234)
    at Qa (react-dom.production.min.js:232)

Zunächst ein wenig Kontext, ich hatte ein Problem im Zusammenhang mit einem Karussellpaket Tiny Slider, das window , also suchte ich nach verschiedenen Karussells mit implementiertem SSR und fand ein reaktionsschnelles Karussell . Ich arbeite großartig mit dem, was ich brauchte, aber nur in develop .

Der erwähnte Fehler tritt in zwei verwandten Szenarien auf:

Szenario 1
Ich verwende gestylte Komponenten, um meine Folie zu stylen , aber das Hinzufügen von beschädigt . Ich fand, dass das Hinzufügen von gatsby-plugin-styled-components das Problem löste; und es funktioniert, aber ... Szenario 2 ist passiert

Szenario 2
Jetzt funktioniert mein Build und ich kann meine Seite mit Stilen sehen. Aber mein Karussell funktioniert nicht, es macht nichts !!! 😱 ... Die Styles sehen aber toll aus ... 😅
Also entferne ich einfach die gatsby-plugin-styled-components und das Skript hat wieder funktioniert, aber nicht meine Stile 🙃

Hoffe, dies gibt einige Hinweise, um das Problem zu finden und zu lösen

Hallo Leute.

Ich bin mir nicht sicher, ob dies hilft, aber ich hatte ein ähnliches Problem. Es stellte sich heraus, dass meine fehlende Ressource eine fehlende (Produktions-) Umgebungsvariable für Firebase war. Dies schien sich wiederum auf meine Bilder auszuwirken - dies muss sich auf einen Build-Schritt ausgewirkt haben

Kann bei Bedarf weitere Informationen bereitstellen ...

@Jivings können Sie Gatsby und Gatsby-Plugin-Offline-Paket aktualisieren? Dies geschieht, wenn Sie einen neuen Build erstellen, aber Ressourcen aus früheren nicht mehr verfügbar sind (daher versucht HTML, das vom Offline-Plugin zwischengespeichert wird, nicht verfügbare Ressourcen zu verwenden). In neueren Gatsby / Offline-Paketversionen haben wir nach Service Worker-Updates ein erneutes Laden hinzugefügt, um die Site nicht im unbrauchbaren Zustand zu belassen

In meinem Fall habe ich einen Import von import { Link } from './' in import { Link } from './Link' geändert (in meiner Datei /components/footer.js ) und den Fehler "Fehlende Ressourcen für /" behoben. Es war eine zirkuläre Abhängigkeit, denke ich. Aber ich weiß nicht, ob es deins reparieren wird
Bearbeiten: Wenn der Fehler regelmäßig auftritt , hat die Lösung von

Ich bekomme diese Fehler aber nur in IE11. Ich bin mir nicht sicher, welche Ressourcen genau ausfallen, da sie, soweit ich das beurteilen kann, nur in einem Browser auftreten, aber ich sehe einige Fehler in der Reaktion (siehe Screenshots unten). Ich habe alle meine Gatsby-Abhängigkeiten auf die neuesten Versionen aktualisiert und eine Polyfüllung hinzugefügt, falls sie an Symbol oder etwas zu

Ich arbeite an meinem in Netlify bereitgestellten Entwicklungszweig, um Korrekturen auf verschiedenen Geräten zu testen.
Hier ist der neueste Debug-Build, wenn Sie ihn testen möchten: https://5c6ee3b943e6c400080a5a8b--marcysutton.netlify.com/about/
Hier ist meine Live-Site, die definitiv noch die ganze Zerbrochenheit in IE11 aufweist: https://marcysutton.com
Und hier ist meine Website-Quelle: https://github.com/marcysutton/gatsby-site

Hier sind einige Screenshots von meiner VM:

@marcysutton Hast du damit Fortschritte gemacht? Ich sehe das gleiche nur in IE11. Keine Probleme in anderen Browsern.

Noch nicht! @sidharthachatterjee oder @pieh , sind dies genug Informationen zum Debuggen? Ziemlich blockierendes Problem im IE11 im Moment.

@Undistraction Ich habe einige gute Neuigkeiten: Das Team hat mir beim Debuggen dieses Problems geholfen und darauf hingewiesen, dass IE11 Probleme mit nicht kompilierten Pfeilfunktionen in einem Plugin hat ( gatsby-background-image ). Sie diskutieren Änderungen am Gatsby-Kern, um dies zu berücksichtigen, aber in der Zwischenzeit sollten Sie in der Lage sein, dies zu umgehen, indem Sie alle Plugins kompilieren, die Probleme verursachen: https://www.gatsbyjs.org/packages/gatsby-plugin- compile-es6-packages /? = kompilieren

Hier ist, wo ich es auf meiner Website verwendet habe: https://github.com/marcysutton/gatsby-site/blob/develop/gatsby-config.js#L107

Lassen Sie uns wissen, wenn Sie noch Probleme haben!

Das gleiche Problem hier, das regelmäßig auf Websites angezeigt wird, die ich seit einigen Tagen nicht mehr besucht habe (auch auf der Gatsby-Website). Nicht auf IE11, sondern auf Chrome. Nach einigen Sekunden leerer Seite erfolgt eine Aktualisierung, nach der alles wieder funktioniert.

Versionen eines Beispiels:
gatsby : 2.0.118
gatsby-plugin-offline : 2.0.23

Ich erhalte diesen Fehler im IE (Edge-Modus).

Es zeigt auf die Datei react-dom.production.min.js in Zeile 1 char 195183.

Wenn Sie im IE auf den Fehler klicken, wird auf diesen Code verwiesen:

if(pi)throw a=qi,qi=null,pi=!1,a;}

@ marcysutton Danke für das Update. Ich hatte diesen Syntaxfehler in Ihrer Konsole nicht entdeckt. Für uns haben wir überhaupt keinen Fehler. Die Seitennavigation ist in IE11 vollständig fehlerhaft und die Seite hydratisiert nicht. Bei einer Seitenaktualisierung wird der Fehler "Fehlende Ressourcen" angezeigt. Wir mussten die IE11-Unterstützung einstellen, da nichts weiter zu tun ist. Keine Probleme mit anderen Browsern. Meine Vermutung ist, dass dies ein Polyfill-Problem ist, aber dass der Fehler irgendwo verschluckt wird, aber das ist nur eine Vermutung. Ich verstehe nicht, wie die Seitenhydratation ohne Fehler in der Konsole abstürzen kann.

Ich erhalte diesen Fehler beim (1.) Laden. Scheint nach dem Nachladen zu löschen. Produktion / Firebase-Hosting.
Error: Missing resources for /

@rkhayat Könnten Sie auf eine URL verlinken oder besser noch eine Reproduktion bereitstellen?

Vielen Dank!

FWIW Ich habe meine Erfahrungen mit diesem Problem unter https://github.com/gatsbyjs/gatsby/issues/12399 niedergeschrieben. Es kann für jeden hilfreich sein, der den Fehler Missing resources for / trifft.

Ich hatte ein ähnliches Problem: Man konnte gut auf der Website navigieren, aber auf jeder Seite, wenn sie aktualisiert wurden, war die Seite leer und ich sah Error: Missing resources for /<path> . Eine harte Aktualisierung oder das Löschen des Cache würde die Seite neu laden, aber normale Aktualisierungen würden wieder eine leere Seite anzeigen.

Da ich dies nicht lokal mit gatsby server reproduzieren konnte, vermutete ich, dass es sich um ein CDN-Problem handelte, und machte das Stammverzeichnis in meiner CloudFront-Distribution ungültig, wodurch dieses Problem anscheinend für mich behoben wurde. Ich bin mir immer noch nicht sicher, was genau passiert ist, aber ich vermute, dass einige Referenzen veraltet sind. Hoffe das hilft jemand anderem.

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!

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

@ gatsbyjs-read-only-user Nicht abgestanden 😬

@Undistraction Ich habe einige gute Neuigkeiten: Das Team hat mir beim Debuggen dieses Problems geholfen und darauf hingewiesen, dass IE11 Probleme mit nicht kompilierten Pfeilfunktionen in einem Plugin hat ( gatsby-background-image ). Sie diskutieren Änderungen am Gatsby-Kern, um dies zu berücksichtigen, aber in der Zwischenzeit sollten Sie in der Lage sein, dies zu umgehen, indem Sie alle Plugins kompilieren, die Probleme verursachen: https://www.gatsbyjs.org/packages/gatsby-plugin- compile-es6-packages /? = kompilieren

Hier ist, wo ich es auf meiner Website verwendet habe: https://github.com/marcysutton/gatsby-site/blob/develop/gatsby-config.js#L107

Lassen Sie uns wissen, wenn Sie noch Probleme haben!

@marcysutton Wie haben Sie die Plugins / Module identifiziert, die nicht kompilierte

@onetwothreebutter Öffnen Sie die kompilierten JavaScript-Dateien im Browser und suchen Sie nach => . IE hat es nicht einfach gemacht zu sagen, woher sie kommen, also habe ich nur manuell mit "Strg + F" gesucht.

Dies sollte sich im Laufe der Zeit im Kern verbessern, aber so können Sie es in der Zwischenzeit überprüfen!

Ich möchte hinzufügen, dass dieses Problem für uns in allen Browsern und Versionen weiterhin besteht, es ist nicht nur IE und scheint durch die Verwendung eines Service Worker in Gatsby ausgelöst zu werden. Verwandte: # 12399

Ich habe auch das gleiche Problem konfrontiert.

• Wenn der Servicemitarbeiter aktiviert ist, führt das Aktualisieren der Seiten zu den oben genannten Fehlern. Dieses Problem trat hauptsächlich in Chrome auf. Der Edge-Browser scheint einwandfrei zu funktionieren (wahrscheinlich, weil der Servicemitarbeiter dort nicht ins Spiel kommt).
• Wenn Sie den Servicemitarbeiter entfernen und das Plugin gatsby-plugin-remove-serviceworker dieses Problem behoben
  Verwendete Auflösung:
• Angesichts der Wichtigkeit, dass der Server-Worker funktionsfähig ist, hat er das Plugin gatsby-plugin-remove-trailing-slashes in Kombination mit dem PWA-Plugin gatsby-plugin-offline ausprobiert, und dies scheint das Problem für mich zu lösen.

Ich habe diesen Fehler und benutze keinen Servicemitarbeiter.
Ich dachte, dass es vielleicht passiert, wenn die Seite mit einer bestimmten Version der Site geladen wird und dann eine Bereitstellung durchgeführt wird und sich die Namen der Assets ändern, sodass sie von der geöffneten Version nicht gefunden werden können.
Außerdem ist die Version, die den Fehler in Sentry verursacht, nicht die Version, die zum Zeitpunkt des Fehlers aktiv war.

@antoinerousseau Ja, nach ein paar Versuchen, das

@KyleAMathews Hast du das gesehen oder hast du irgendwelche Informationen?

@jackhair es ist schwer zu sagen, was ohne Reproduktion passiert. http://gatsby.dev/reproduction

Problemumgehung: https://github.com/gatsbyjs/gatsby/issues/13410#issuecomment -486306784

@smakosh Ich

Das Offline-Plugin verwendet es

Ok, aber ich meine, dass der Fehler auch ohne dieses Plugin auftritt.

Können Sie überprüfen, ob Sie die Registrierung der Software erfolgreich aufgehoben haben, wie Sie sie möglicherweise bereits verwendet haben? Löschen Sie auch Ihren Gatsby-Cache, indem Sie die Ordner public und .cache löschen

Ich habe bei diesem Projekt nie eine Software verwendet. (und nur für den Fall überprüft)
public und .cache werden immer von Netlify neu erstellt.
Fehler in der Produktion werden von Sentry gemeldet.
https://sentry.io/share/issue/738b234836814442b7702866c6814fdf/

Ist Ihr Projekt Open Source? Wenn ja, können Sie unten einen Link erstellen. Ich würde es gerne überprüfen und sehen, wie ich das beheben kann

Tut mir leid, aber im Grunde ist es eine Gatsby-Site, die von Netlify bereitgestellt wird ...

  "dependencies": {
    "@sentry/browser": "^5.1.1",
    "@types/algoliasearch": "^3.30.8",
    "@types/dotenv": "^6.1.0",
    "@types/he": "^1.1.0",
    "@types/jump.js": "^1.0.2",
    "@types/node": "^11.13.7",
    "@types/node-fetch": "^2.3.3",
    "@types/react": "^16.8.14",
    "@types/react-dom": "^16.8.4",
    "@types/source-map-support": "^0.5.0",
    "@types/standard-http-error": "^2.0.0",
    "@types/styled-components": "^4.1.14",
    "algoliasearch": "^3.32.0",
    "aws-sdk": "^2.443.0",
    "babel-plugin-styled-components": "^1.10.0",
    "date-fns": "^2.0.0-alpha.27",
    "gatsby": "^2.3.31",
    "gatsby-image": "^2.0.40",
    "gatsby-plugin-google-analytics": "^2.0.18",
    "gatsby-plugin-manifest": "^2.0.29",
    "gatsby-plugin-netlify": "^2.0.15",
    "gatsby-plugin-offline": "^2.0.24",
    "gatsby-plugin-react-helmet": "^3.0.12",
    "gatsby-plugin-sharp": "^2.0.35",
    "gatsby-plugin-styled-components": "^3.0.6",
    "gatsby-plugin-typescript": "^2.0.13",
    "gatsby-source-filesystem": "^2.0.32",
    "gatsby-transformer-sharp": "^2.1.18",
    "he": "^1.2.0",
    "hyphenslug": "^1.0.0",
    "intersection-observer": "^0.6.0",
    "jump.js": "^1.0.2",
    "mkdirp2": "^1.0.4",
    "mustache": "^3.0.1",
    "node-fetch": "^2.3.0",
    "nodemailer": "^6.1.1",
    "prop-types": "^15.7.2",
    "react": "^16.8.3",
    "react-dom": "^16.8.3",
    "react-helmet": "^5.2.0",
    "sitemap": "^2.1.0",
    "source-map-support": "^0.5.12",
    "standard-http-error": "^2.0.1",
    "strip": "^3.0.0",
    "styled-components": "^4.1.3",
    "ts-node": "^8.1.0",
    "typescript": "^3.4.5",
    "whatwg-fetch": "^3.0.0"
  },

Ich sehe das Offline-Plugin installiert. Können Sie bestätigen, dass es nicht in Ihrer gatsby-config-Datei enthalten ist?

Ja, tut mir leid, aber nicht verwendet. Hier ist meine Gatsby-Konfiguration:

module.exports = {
  siteMetadata: {/*...*/},
  plugins: [
    `gatsby-plugin-typescript`,
    `gatsby-plugin-styled-components`,
    `gatsby-plugin-react-helmet`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images`,
      },
    },
    {
      resolve: `gatsby-plugin-sharp`,
      options: {
        defaultQuality: 80,
      },
    },
    `gatsby-transformer-sharp`,
    {
      resolve: `gatsby-plugin-manifest`,
      options: {
        name: `Le Bikini`,
        short_name: `Le Bikini`,
        start_url: `/`,
        background_color: `#000000`,
        theme_color: `#000000`,
        display: `minimal-ui`,
        icon: `src/images/favicon.png`,
      },
    },
    `gatsby-plugin-netlify`,
    {
      resolve: `gatsby-plugin-google-analytics`,
      options: {
        trackingId: process.env.GOOGLE_ANALYTICS,
        head: false,
        anonymize: true,
        respectDNT: true,
      },
    },

    // this (optional) plugin enables Progressive Web App + Offline functionality
    // 'gatsby-plugin-offline',
    // To learn more, visit: https://gatsby.app/offline
  ],
}

Und Sie können es live unter https://lebikini.netlify.com sehen

Ich kann ohne ein Reproduktions-Repository nicht helfen, da ich mehr Dinge zum Debuggen überprüfen muss

Sei vorsichtig @antoinerousseau
gatsby-plugin-netlify Plugin
https://www.npmjs.com/package/gatsby-plugin-netlify

@abumalick @antoinerousseau Wir verschieben gatsby-plugin-netlify an das Ende unseres Plugin-Arrays und es hat nichts geändert.

Vielleicht hat das etwas damit zu tun? https://github.com/gatsbyjs/gatsby/issues/11982

Wann immer ich selbst auf das Problem gestoßen bin (reiner Zufall), hat es immer einen Fehler, der mit dem Fehlen eines Seitenmanifests zu tun hat.

Ich habe das einzige Update beschrieben, das in allen Fällen in einem verwandten Problem funktioniert: https://github.com/gatsbyjs/gatsby/issues/12399#issuecomment -488247566

Ich hatte das gleiche Problem. Mein Fall war der gleiche wie bei @ efd1 - der Import in Form von import { Module } from "." meinen Produktionsaufbau unterbrochen (die Entwicklung funktionierte ohne Probleme). Es war leider nicht sehr einfach zu debuggen und zu finden.

Die obigen Vorschläge scheinen für mich nicht zu funktionieren. Ich sehe dies nur für iOS-Benutzer und nur sporadisch. Ich kann es scheinbar nicht replizieren und daher ist es schwer herauszufinden, was falsch sein könnte. Irgendwelche Tipps, wie Sie herausfinden können, was das zugrunde liegende Problem sein könnte?

Um Kyles obige Aussage wiederzugeben, benötigen wir reproduzierbare Demo-Sites, um helfen zu können. http://gatsby.dev/reproduction

Es ist schwer zu sagen, was ohne Reproduktion passiert. http://gatsby.dev/reproduction

@KyleAMathews Ehrlich gesagt denke ich, dass dies auf jeder Gatsby-Site geschieht, die für Netlify bereitgestellt wird und mehrere Seiten umfasst. Werfen Sie Sentry auf einen und überzeugen Sie sich selbst.

Ich würde sagen, diese Aussage ist etwas verfrüht, da beispielsweise alle meine Gatsby-Projekte für Netlify bereitgestellt werden und ich den Fehler (in den letzten Monaten) nie gesehen habe. Eine Reproduktion wäre in der Tat sehr hilfreich.

@LekoArts @marcysutton Die Sentry Spur noch öffentlich verfügbar ist hier .

Hilft das überhaupt?

Der Fehler tritt an meinem Produktionsstandort ungefähr einmal pro Tag auf.

Ich würde sagen, diese Aussage ist etwas verfrüht, da beispielsweise alle meine Gatsby-Projekte für Netlify bereitgestellt werden und ich den Fehler (in den letzten Monaten) nie gesehen habe. Eine Reproduktion wäre in der Tat sehr hilfreich.

@lekoarts Hast du ein Sentry-Setup? Wie viel Verkehr?

Der Fehler tritt an meinem Produktionsstandort ungefähr einmal pro Tag auf.

@ Jivings Wie viel Verkehr? Ich versuche mir ein Bild von der Frequenz zu machen.

Soweit ich das beurteilen kann, habe ich seit dem 1. März 541 Fälle dieses Fehlers in 160.000 Seitenaufrufen (47.000 Sitzungen) auf einer von mir gepflegten Website festgestellt. Dies ist eine Wahrscheinlichkeit von 0,3%, dass ein Seitenaufruf das Verhalten auslöst, oder eine Wahrscheinlichkeit von 1,2%, dass eine Sitzung es erfährt. Nicht großartig, was Reproduktionen betrifft; Wir werden wahrscheinlich altmodische Spuren, Ermittlungen und andere Fehlerbehebungen benötigen, um dies herauszufinden.

Es ist häufiger auf Mobilgeräten, aber mehr Besuche finden auf Mobilgeräten statt, und dies geschieht auch auf dem Desktop. Make / model / browser scheint irrelevant zu sein. Für das, was es wert ist, ist dies eine Streaming-Audio-Plattform, daher sehen wir in der Regel viel längere Sitzungsdauern als Websites, die auf Marketing ausgerichtet sind oder viel In- und Out-Verkehr sehen.

Hat jemand diesen Fehler in der Produktion gesehen, ohne Sentry zu verwenden? Jemand, der Honeybadger, Raygun, Rollbar, Airbrake oder ähnliches benutzt?

@coreyward Ich sehe es auch zeitweise mit Raygun. Es ist nur auf einer bestimmten Seite und wirkt sich nur auf Mobile Safari und Chrome aus.

@coreyward Wir verwenden Bugsnag und haben es im letzten Monat ungefähr 4,8.000 Mal gesehen.

@coreyward Vielleicht ist das hilfreich:

(von https://github.com/gatsbyjs/gatsby/issues/12399#issuecomment-480082161)

Wir verwenden Bugsnag und sehen, dass dies für etwa 1% des Verkehrs angezeigt wird. Browser scheinen in etwa unserer gesamten Verkehrsverteilung zu entsprechen und sehen dort keine klaren Muster.

@coreyward Scheint ungefähr 1% des Verkehrs für uns zu beeinflussen.

@KyleAMathews Hey, ich bin gerade auf diesen Fehler auf der GatsbyJS-Produktionswebsite gestoßen. Nach ein paar Aktualisierungen verschwand das Problem.

Bei der Verwendung des Offline-Plugins und der Bereitstellung im Azure-Blob-Speicher sowie im CDN ist dieses Problem aufgetreten. Ich habe gelesen, dass der Service Worker js nicht vom CDN bedient werden darf und direkt von der Serverdomäne kommen sollte. Vielleicht ist das die Grundursache.

Wir haben ers-hcl.github.io, das mit dem auf ghpages aktivierten Offline-Plugin und Service Worker bereitgestellt wird. Dort ist dieses Problem nie aufgetreten, was wahrscheinlich auf meinen früheren Kommentar in Bezug auf das Problem im Zusammenhang mit der CDN-Behandlung des Offline-Plugins hinweist

Dieses Problem hat nichts mit dem Offline-Plugin zu tun. Wenn Sie das Offline-Plugin verwenden, müssen Sie die Benutzer erneut laden oder eine Push-Benachrichtigung anzeigen, dass neue Inhalte zum Aktualisieren der Software verfügbar sind.

@smakosh Immer wenn wir das Offline-Plugin deaktivieren,

Wir sehen es und verwenden das Offline-Plugin nicht.

• Ich kann mich irren - eine Beobachtung in der Datei ensure-resources.js , die die Komponente ist, die diesen Fehler auslöst, aber nur für den Fall erwähnt werden sollte.
• Wenn man sich den Code für ensure-resources.js , scheint er window.location in Zeile Nr. 81 zu verwenden, da es eine Eigenschaft location gibt, die in dieser Komponente in allen verwendet wird andere Plätze.

Ich bezweifle, dass unsere besondere Situation für viele andere hilfreich sein wird, aber ich wollte sie hier nur für den Fall teilen.

Dies betraf DataCamp.com aufgrund eines CORS-Problems. Wir verwenden Asset-Präfix- und Hosting-Assets in S3, die über Cloudfront bereitgestellt werden. Bei unserer ersten Bereitstellung mit Asset-Präfix haben wir vergessen, CORS-Header in S3 festzulegen, um den Zugriff auf die Assets von unserer Domäne aus zu ermöglichen (oops). Wir haben unsere CORS-Header nach ein oder zwei Minuten aktualisiert, aber alle Randknoten, auf denen die Assets bereits aufgerufen wurden, haben anscheinend nicht nur den Asset-Inhalt, sondern auch die CORS-Header zwischengespeichert! Dies erzeugte die Illusion, dass ein seltsamer Fehler nur einen kleinen Prozentsatz der Benutzer betraf, obwohl in Wirklichkeit das Problem darin bestand, dass ein kleiner Prozentsatz der Randknoten die alten Header zwischengespeichert hatte. Wir haben dieses Problem gelöst, indem wir in Cloudfront eine Ungültigmachung für alle Assets erstellt haben.

Allgemeiner: Wenn einer Ihrer Benutzer einen Adblocker hat, der einen bestimmten Asset-Namen als potenziell werbe- oder nachverfolgungsbezogen aufnimmt, gibt es zu irgendeinem Zeitpunkt zwischen Ihrem Asset-Server und dem Endbenutzer einen Mittelsmann, der möglicherweise Header für einen kleinen ändert Prozentsatz Ihrer Benutzer (z. B. ein Unternehmensnetzwerk, das Inhalte filtert) oder wenn ein anderes seltsames Netzwerk passiert, scheint dies alles zu diesem Fehler beizutragen.

Wir hatten das gleiche Problem und es stellte sich heraus, dass der Hauptgrund dafür zirkuläre Abhängigkeiten waren

@bigfanjs könntest du da etwas näher darauf eingehen?

@DSchau Nun, kürzlich hat ein Teamkollege eine Funktion hinzugefügt und wir haben sie bereitgestellt. Der Browser beschwert sich über ein ähnliches Problem. Wir hatten keine Idee. Mein Teamkollege hat eine Seite und eine große gemeinsame wiederverwendbare Komponente erstellt. Also haben wir den Code sowohl auf der Seite als auch in der Komponente kommentiert und stattdessen ein <div /> -Tag gerendert. Und lief gatsby build und dann gatsby serve um die Serverproduktion lokal aufzubauen. und wir begannen einzugrenzen, indem wir Code kommentierten und jedes Mal die obigen Empfehlungen ausführten. mögen:

import {Button} from "components/kit"

// comment the rest to see if `Button` is causing the issue
// import {Box} from "components/kit"
// import {Form} from "components/kit" 

Das nächste Mal kommentieren wir Box und so weiter ...

Schließlich stellt sich heraus, dass der Fehler einfach ist.

Wir haben eine gemeinsame Komponente namens kit die einige Komponenten importiert:

Komponenten / Kit

| --- Box.js
| --- Button.js
| --- Form.js
| --- index.js

index.js

export { default as Box } from "./Box"
export { default as Button } from "./Button"
export { default as Form } from "./Form"

Zum Beispiel haben wir in Form versucht, Box diese Weise zu importieren:
import {Box} from "components/kit"

Aber das verursacht das Problem, wir haben es so geändert:
import {Box} from "./Box"

und es hat funktioniert.

hoffentlich hilft das.

Das gleiche Problem hier, das regelmäßig auf Websites angezeigt wird, die ich seit einigen Tagen nicht mehr besucht habe (auch auf der Gatsby-Website). Nicht auf IE11, sondern auf Chrome. Nach einigen Sekunden leerer Seite erfolgt eine Aktualisierung, nach der alles wieder funktioniert.

Versionen eines Beispiels:
gatsby : 2.0.118
gatsby-plugin-offline : 2.0.23

Ich hatte einen ähnlichen Fehler mit diesem. Und ich konnte beim Erstellen der Produktion nicht auf die NetLify-CMS-Administrationsseite zugreifen.
Und ich fand heraus, dass dies an der Nichtübereinstimmung der Gatsby- und Gatbsy-Plugin-Offline-Version liegt.
Daumen hoch!!!

Für Leute, die diesen Fehler gelegentlich sehen - das ist tatsächlich zu erwarten -, wenn Sie eine neue Version Ihrer Site bereitstellen, löschen die meisten Hosts ältere Versionen der Site, was bedeutet, dass jeder, der bereits auf der Site ist und versucht, zu einer Seite zu navigieren, dies nicht tut Wenn Sie in der Lage sind, die Ressourcen für diese Seite zu finden, wird dieser Fehler ausgelöst und eine vollständige Aktualisierung ausgelöst, indem Sie den HTML-Code für die Seite erneut abrufen.

Die Tests hierzu finden Sie hier: https://github.com/gatsbyjs/gatsby/blob/cbbed1dde8a4fd25080e9ab65d7661dfa8fbf327/e2e-tests/production-runtime/cypress/integration/resource-loading-resilience.js

@KyleAMathews Es scheint, dass die Aktualisierung nicht durch diesen fehlenden Ressourcenfehler ausgelöst wird, sodass ein Benutzer auf einer kaputten oder nur weißen Seite feststeckt. Benötigen wir das Offline-Plugin, um sicherzustellen, dass die Aktualisierung erfolgt?

Nein ... wenn das passiert, dann ist es ein Fehler in Gatsby. Haben wir eine Reproduktion für das von Ihnen beschriebene Szenario?

- -
Kyle Mathews

Blog: http://bricolage.io
Twitter: http://twitter.com/kylemathews

Am Dienstag, den 04. Juni 2019 um 15:05 Uhr schrieb Jack <[email protected]>:

@ KyleAMathews (https://github.com/KyleAMathews) Es scheint die Aktualisierung
wird durch diesen fehlenden Ressourcenfehler nicht ausgelöst, sodass ein Benutzer stecken bleibt
auf einer kaputten oder nur weißen Seite. Müssen wir das Offline-Plugin haben?
Sicherstellen, dass die Aktualisierung erfolgt?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an (
https://github.com/gatsbyjs/gatsby/issues/11524?
) oder schalten Sie den Thread stumm (
https://github.com/notifications/unsubscribe-auth/AAARLB7QKXUL3AZF4MXCO33PY3RLFANCNFSM4GUAYCZA
).

@KyleAMathews Abgesehen davon, dass ich es auf unserer Produktionsstätte getroffen oder verpasst habe, konnte ich es nicht lokal reproduzieren. Für eine Reproduktion müsste ein völlig neues Repo mit Netlify-Integration eingerichtet werden. Aktualisieren Sie dann weiter, bis Sie schließlich darauf stoßen.

Es scheint, dass @coreyward es auf der Gatsby-Website weiter oben in den Kommentaren abgefangen hat.

Ebenfalls relevant für diese Diskussion ist, dass @Moocar an einem großen Refaktor für das Laden von Daten zur Laufzeit https://github.com/gatsbyjs/gatsby/pull/13004 gearbeitet hat

Ich habe im Moment keine Reproduktion, aber ich kann bestätigen, dass ich dies mindestens ein halbes Dutzend Mal gesehen habe, wo es nicht von selbst aktualisiert wurde.

@KyleAMathews Wir sehen, dass dies bei 1% der Anfragen in allen Browsern völlig unabhängig vom Zeitpunkt der Bereitstellung geschieht. Wir werden feststellen, dass dies sonntags mit der gleichen Geschwindigkeit geschieht, selbst wenn die letzte Bereitstellung am Freitag erfolgte. Hier ist ein Bugsnag-Screenshot, um die relative Konsistenz über die Zeit zu veranschaulichen (natürlich immer noch ein wenig Klumpen aufgrund normaler Verkehrsschwankungen):

@gwlortscher sehr interessant - scheint also nicht mit

Nur um eine mögliche Ursache hinzuzufügen:
In meinem Fall war es ein new Buffer(val, 'base64').toString(); als Ersatz für atob in SSR.
(Wenn atob nicht verfügbar ist, verwenden Sie grundsätzlich die Version node-js.)
Arbeitete in der Entwicklung, richtig kompiliert, stürzte beim Start der Produktseite ab. Außerdem war das Include ausreichend, der Code wurde nie ausgeführt, er war nur in dem Block vorhanden, der beim Start geladen werden würde.

@KyleAMathews Bugsnag scheint kein% -Anforderungsdiagramm zu haben, ist aber einfach genug, um es aus Analysen zu berechnen. Hier sind die letzten 8 Tage (Fehler als Prozentsatz der Anfragen):

6/1 2,4%
6/2 2,3%
6/3 2,2%
6/4 2,4%
6/5 2,4%
6/6 2,1%
6/7 2,4%
6/8 2,4%

Wir haben dies zum ersten Mal beim Upgrade auf Gatsby v2.9.4 gesehen. Durch Zurücksetzen auf 2.8.5 wurde das Problem behoben. Ich versuche immer noch, die Ursache zu analysieren.

Wir hatten das gleiche Problem und sahen es auch durch ein Downgrade auf 2.8.5 behoben. Vorher haben wir ständig Fehler für fehlende Ressourcen für "/" erhalten.

@bmatzner @wilcoxmd Wir sind schon eine Weile auf 2.8.x und haben bei jedem Gatsby-Upgrade fehlende Ressourcen, seit wir zum ersten Mal von Version 1 auf Version 2 gewechselt sind . Konsequent keine Spitze oder Änderung beim Upgrade seit v2.

Wir haben definitiv schon lange vor 2.8.5 gesehen. Ich denke, dieses Problem hat eine Vielzahl von Ursachen. v2.94 scheint nur noch eine eingeführt zu haben.

@bmatzner @wilcoxmd Wir sind schon eine Weile auf 2.8.x und haben bei jedem Gatsby-Upgrade fehlende Ressourcen, seit wir zum ersten Mal von Version 1 auf Version 2 gewechselt sind . Konsequent keine Spitze oder Änderung beim Upgrade seit v2.

Gleich

@ Jackhair Ich

@ Jackhair Ich

Interessant. Für das, was es wert ist, war es uns nie möglich, das Problem lokal zu replizieren (Gatsby Develop). Nur wenn es auf einer Produktionsumgebung basiert, sehen wir das Problem.

Wir haben eine Produktniederlassung in 2.9.2, die vielversprechend aussieht, bisher keine Probleme, aber der Verkehr dazu ist im Vergleich zur Hauptproduktion winzig. Ich werde die Ergebnisse veröffentlichen, sobald wir sie bereitgestellt haben, in der Hoffnung, dass das Update des Seitenmanifests für Gatsby letzte Woche viel hilft.

Wir haben 2.9.0 in der Produktion und sehen das Problem leider immer noch mit der gleichen Rate wie zuvor - 1-2% des Datenverkehrs in allen Browsern.

Der Rollback der Version von 2.9.4 auf 2.8.5 2.9.4 scheint das Problem für uns behoben zu haben.
In unserem Fall scheint es sich um einige fehlende pages-manifest-{hash}.js[.map] -Dateien zu handeln.
Die Versionen 2.9.3 und 2.9.4 weisen einige potenzielle Änderungen auf: siehe https://github.com/gatsbyjs/gatsby/pull/14732 (aus den Änderungsprotokollen des Gatsby-Pakets: https://github.com) /gatsbyjs/gatsby/blob/master/packages/gatsby/CHANGELOG.md).
Um dies zu bestätigen, sollte ein letzter Test für uns darin bestehen, Gatsby auf 2.9.2 zu aktualisieren.

Zu Ihrer Information, @moocar verfügt über eine PR, um das Laden von Ressourcen robuster zu gestalten, z. B. erneut versuchte oder teilweise geladene Ressourcen https://github.com/gatsbyjs/gatsby/pull/14889

Wenn jemand von euch Zeit hat, dies zu überprüfen / zu versuchen, wäre er sehr dankbar. Ich entschuldige mich dafür, dass ich das nicht früher verstanden habe - es war nicht klar, wie weit verbreitet dies war oder was die Ursache war, bevor ich mich kürzlich mit @Moocar befasst habe

Ich weiß nicht, ob es mehr helfen wird, aber ich hatte es vor ein paar Minuten auf https://gatsbyjs.org/contributing :

Wurde nach einem Nachladen behoben, schien es aber wert, hier @KyleAMathews zu setzen

Ich glaube, dies könnte ein Problem mit der Offline-Plugin-Konfiguration sein, da sie möglicherweise nicht korrekt nach Änderungen mit Seitenmanifestdateien sucht und daher alte beibehalten.

Ich werde versuchen, mir diese nächste Woche mit @wardpeet anzuschauen, da ich viel Offline-Plugin geschrieben habe.

@ davidbailey00 Bevor Sie zu tief in das Debuggen

@ davidbailey00 wir hatten auch das Problem ohne das Offline-Plugin. Es befindet sich in meinen Knotenmodulen, ist aber immer noch aus meiner Konfigurationsdatei heraus kommentiert.

Wir erleben dies auch ohne das installierte Offline-Plugin.

@ davidbailey00 Ja, wir glauben, dass die Hauptkorrektur darin besteht, einige ungewöhnliche https://github.com/gatsbyjs/gatsby/pull/14889

Wir haben die PR in den letzten ~ 4-5 Tagen auf gatsbyjs.org bereitgestellt und die Dinge sehen wirklich gut aus! Seit der Bereitstellung sind keine neuen Ereignisse "Fehlende Ressourcen" aufgetreten.

https://github.com/gatsbyjs/gatsby/pull/14889#issuecomment -505872897

@wardpeet arbeitet an einigen Tests, um Netzwerkprobleme zu simulieren, aber wir sollten dies in den nächsten 24 Stunden herausbringen.

Vielen Dank, dass Sie @KyleAMathews es kaum erwarten können, dies zum Laufen zu bringen!

@KyleAMathews danke dir und deinem Team für das Update!

@KyleAMathews Ich habe dieses Problem immer noch auf meiner Website. lokal funktioniert es gut und in prod nicht. Außerdem sehe ich es 100% der Zeit, nicht sporadisch wie einige der obigen Kommentare. Trotzdem habe ich die meisten Lösungen durchgesehen und ihre Verwendung hat nicht zu einer Lösung geführt. Haben Sie eine bestimmte Version von Gatsby, die das Update enthält, damit ich sicherstellen kann, dass ich etwas anderes treffe?

Ich bin bereit, URLs privat zu teilen und Contrib-Zugriff auf das private Repo hinzuzufügen, wenn jemand aus dem Gatsby-Team einen Blick darauf werfen möchte (DM me auf Twitter ). Vielen Dank für alle Tipps / Vorschläge - um klar zu sein, die Dinge, die ich getestet habe, sind:

• Hinzufügen von Service Worker Reload auf gatsby-browser.js
• Offline-Plugin entfernen
• Aktualisieren aller Knotenmodule
• Stellen Sie sicher, dass die Importe nicht mit . referenziert werden

Wir sollten dieses Problem in der neuesten Gatsby-Version [email protected] beheben lassen. Wir haben es auf gatsbyjs.org ausgeführt und die Fehler sind für uns verschwunden.

Bitte aktualisieren Sie und lassen Sie uns wissen, wenn es weitere Probleme gibt! Schließen Sie dies vorerst.

@KyleAMathews Danke - ich habe es getan, leider wurde dies nicht

@KyleAMathews Danke - ich habe es getan, leider wurde dies nicht

Fehlende Ressourcen werden nicht angezeigt, da sie gelöscht und durch einen anderen Fehler ersetzt wurden: https://github.com/gatsbyjs/gatsby/pull/14889/files#diff -3182dbe2979ea0744c50242668edc572L173

Wir haben dieses Update kürzlich bereitgestellt und die Fehlerprotokolle auf neue / andere Fehler überprüft.

EDIT: Ja, es sieht so aus, als ob this.loadPageDataJson(...).then(...).finally is not a function das neue missing resources

@jackhair Mit welchem ​​Browser

Hast du etwas dagegen, dein Repo zu teilen? oder eine kleine Reproduktion?

@jackhair Mit welchem ​​Browser

Hast du etwas dagegen, dein Repo zu teilen? oder eine kleine Reproduktion?

Wir sehen dies in mehreren Browsern in der Produktion:

Haben Sie etwas dagegen, Ihre Website-URL zu teilen, damit ich sie mir ansehen und sie vielleicht ein bisschen debuggen kann?

Haben Sie etwas dagegen, Ihre Website-URL zu teilen, damit ich sie mir ansehen und sie vielleicht ein bisschen debuggen kann?

Sicher! https://ritual.com

@jackhair Ich kann den Fehler bestätigen. Könnten Sie ein neues Problem mit den oben angegebenen Informationen machen?

@wardpeet @jackhair Wir bekommen auch dieses finally Polyfill-Problem. Gibt es ein neues Problem? Kann es das bitte ref?

@eknowles @wardpeet Leider hatte ich noch keine Zeit, ein Bug-Ticket dafür zu schreiben. Wenn Sie einen freien Moment haben und einen erstellen möchten, kann ich ihn auch mit meinen eigenen Daten sichern.

@wardpeet @jackhair Ich habe es geschafft, unser Problem mit der endgültigen Polyfüllung aufzuspüren .

Wir haben festgestellt, dass eine unserer Abhängigkeiten darin bestand, babel-polyfill mit useBuiltins einzuschließen: usage statt entry.

In beiden Fällen mussten wir die Redux-API-Middleware (nicht im Zusammenhang mit Gatbsy) herabstufen.
https://github.com/agraboso/redux-api-middleware/compare/v2.3.0...v3.0.0

Dies löste unseren finally Fehler. Ich würde empfehlen, dem Stack-Trace entlang der Kette zu folgen und zu sehen, welche Bibliothek der Schuldige ist, da die Promise-Polyfüllung möglicherweise überschrieben wird, aber eine böse Bibliothek ist.

Danke, wir haben das schon mit node_modules und babel-runtime gesehen. Ich muss überdenken, wie wir dies in Zukunft beheben können, oder zumindest eine richtige Fehlermeldung geben.