Gatsby: Error / recursos de página para / no encontrados. No renderizar React

Hola!

Este tema se ha silenciado. Silencio espeluznante. 👻

Tenemos muchos problemas, por lo que actualmente los cerramos después de 30 días de inactividad. Han pasado al menos 20 días desde la última actualización aquí.
Si nos perdimos este problema o si desea mantenerlo abierto, responda aquí. ¡También puede agregar la etiqueta "no obsoleto" para mantener este problema abierto!
Como recordatorio amistoso: la mejor manera de ver este problema, o cualquier otro, solucionado es abrir una solicitud de extracción. Consulte gatsby.dev/contribute para obtener más información sobre la apertura de relaciones públicas, la clasificación de problemas y la contribución.

¡Gracias por ser parte de la comunidad de Gatsby! 💪💜

@antoinerousseau ¿ayudaría si proporcionáramos un mejor seguimiento de pila? Como tal vez fuera 404 o tal vez los datos de la página no fueran válidos. Por el momento, realmente no ves la diferencia.

¿Cuál crees que podría ser la mejor manera de avanzar? ¿Lo probaste tú mismo en un safari / safari móvil?

@wardpeet gracias por investigar esto.
Lo intenté con el escritorio de Safari y no pude reproducirlo. No tengo un iPhone.
No estoy seguro de cómo proceder, ya que sucede solo a veces y al azar, pero un mejor seguimiento de pila no puede hacer daño de todos modos.
Tenga en cuenta que solo sucedió 124 veces, con 85% Mobile Safari, 10% Safari y 5% Chrome Mobile iOS. Varias versiones.
Además, la URL no siempre es / . Puedo darte acceso a la cuenta de Bugsnag si quieres.

Hoy he tenido el mismo informe de error. Solo para hacerte saber que no estás solo.

Hola!

Este tema se ha silenciado. Silencio espeluznante. 👻

Tenemos muchos problemas, por lo que actualmente los cerramos después de 30 días de inactividad. Han pasado al menos 20 días desde la última actualización aquí.
Si nos perdimos este problema o si desea mantenerlo abierto, responda aquí. ¡También puede agregar la etiqueta "no obsoleto" para mantener este problema abierto!
Como recordatorio amistoso: la mejor manera de ver este problema, o cualquier otro, solucionado es abrir una solicitud de extracción. Consulte gatsby.dev/contribute para obtener más información sobre la apertura de relaciones públicas, la clasificación de problemas y la contribución.

¡Gracias por ser parte de la comunidad de Gatsby! 💪💜

¡Hola de nuevo!

Han pasado 30 días desde que sucedió algo sobre este tema, por lo que nuestro amigable robot del vecindario (¡ese soy yo!) Lo cerrará.
Tenga en cuenta que solo soy un robot, por lo que si cerré este problema por error, soy HUMAN_EMOTION_SORRY . No dude en volver a abrir este problema o crear uno nuevo si necesita algo más.
Como recordatorio amistoso: la mejor manera de ver este problema, o cualquier otro, solucionado es abrir una solicitud de extracción. Consulte gatsby.dev/contribute para obtener más información sobre la apertura de relaciones públicas, la clasificación de problemas y la contribución.

¡Gracias nuevamente por ser parte de la comunidad de Gatsby! 💪💜

Viendo lo mismo.

• Es razonablemente frecuente (lo vemos a diario).
• Casi todos Mobile Safari o Safari.
• Casi siempre / , pero muy raramente otras páginas.
• Sentry proporciona el mismo seguimiento de pila que Bugsnag con las siguientes rutas de navegación:
  

Igual que aquí. Para una página que no sea / index.

Dispositivo
Marca | Huawei
Familia | DRA-LX5

SO
Nombre | Androide
Versión | 8.1.0

Navegador
nombre | Vista web móvil de Chrome
versión | 70.0.3538

SDK
Nombre | sentry.javascript.browser
Versión | 5.12.1

Hola!

Este tema se ha silenciado. Silencio espeluznante. 👻

Tenemos muchos problemas, por lo que actualmente los cerramos después de 30 días de inactividad. Han pasado al menos 20 días desde la última actualización aquí.
Si nos perdimos este problema o si desea mantenerlo abierto, responda aquí. ¡También puede agregar la etiqueta "no obsoleto" para mantener este problema abierto!
Como recordatorio amistoso: la mejor manera de ver este problema, o cualquier otro, solucionado es abrir una solicitud de extracción. Consulte gatsby.dev/contribute para obtener más información sobre la apertura de relaciones públicas, la clasificación de problemas y la contribución.

¡Gracias por ser parte de la comunidad de Gatsby! 💪💜

Sigue siendo un problema.

También tengo este problema. gatsby develop funciona bien, pero gatsby build hace que la aplicación se rompa con "Error: recursos de la página para / no encontrados. No se procesa React". en tiempo de ejecución a pesar de que la propia compilación tiene éxito.

¿Podría ser causado por el hecho de que estoy usando TypeScript?

He intentado ejecutar gatsby clean

Actualización / posible solución : Para mí, el error se debió a que solo tenía un archivo ".env.development" y no un archivo ".env.production". Sin embargo, no sé por qué esto dio un error tan ambiguo / confuso y evitó que React se procesara. Siento que el comportamiento esperado sería el mismo que el que ocurre cuando ejecuto gatsby develop . Cuando ejecuto gatsby develop y no tengo un archivo .env.development, React todavía se procesa pero mi aplicación falla porque faltan los valores importantes.

Tengo el mismo problema. Mi aplicación está alojada en AWS y usa Cloudfront. Tengo una política para redirigir todas las URL que no existen a la página 404.html con estado 200 . Parece extraño, pero es realmente importante para una de nuestras funciones. Entonces, en caso de que escriba algo como my-test-site.com/some-not-existed-page window.pagePath sería /404.html que es correcto, pero publicLoader.loadPage alguna manera intenta cargar no un 404.html contenido de la página, pero /my-test-site.com/some-not-existed-page . De hecho, usa window.location.pathname pero no window.pagePath

Recibí el mismo mensaje de error en Sentry hoy: no encontrado. No renderizar React

También me estaba encontrando con este problema. Para mí, era reproducible al usar importaciones con nombre para sus propios componentes en el archivo pages/index.js .

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

components/index.js se vería así:

import Layout from "./Layout"

export {
  Layout
};

Esto fue con MacOS catelina & chrome versión 80.0.3987.149.
"gatsby": "^2.20.13",

Es importante tener en cuenta que estoy usando la variante expo gatsby.

También tuve este problema al ejecutar un gatsby build limpio y la causa raíz fue una resolución en mi package.json para una vulnerabilidad del paquete acorn (consulte https://snyk.io/vuln/npm :bellota):

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

Eliminar esta resolución resolvió el problema para mí.

Salida de gatsby info :

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

Todavía sucede mucho (más de 4500 veces durante la última semana):

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

/app-ac76ae7860adc4ef4414.js:1:179819

Migas de pan:

Tiempo | Tipo | Error | Infos
- | - | - | -
4 ms antes | SOLICITUD | Error XMLHttpRequest | OBTENER /page-data/app-data.json
5ms antes | SOLICITUD | Error XMLHttpRequest | OBTENER /page-data/index/page-data.json
6 ms antes | SOLICITUD | Error XMLHttpRequest | OBTENER /page-data/app-data.json
7 ms antes | SOLICITUD | Error XMLHttpRequest | OBTENER /page-data/index/page-data.json
10 ms antes | SOLICITUD | Error XMLHttpRequest | OBTENER /page-data/app-data.json
10 ms antes | SOLICITUD | Error XMLHttpRequest | OBTENER /page-data/index/page-data.json

La mayoría de ellos ocurren en Mobile Safari y Chrome Mobile:

Versión de Gatsby: 2.20.13

Compruebe esta solución.
https://github.com/gatsbyjs/gatsby/issues/11461#issuecomment -459732145

No uso gatsby-plugin-offline por lo que no hay trabajadores de servicio.

¿Hay algún avance? Tengo un problema y tengo un complemento sin conexión, y no puedo deshabilitar el complemento para probar si se producen errores.

No creo que esto tenga nada que ver con el complemento sin conexión. Estamos viendo muchos de estos errores y nunca los hemos usado.

Reproducir:

• Vaya a [el ejemplo ya no es necesario, ver más abajo], observe el error en la consola y React no funcional.
• Navega a la página de inicio con el logo en la parte superior izquierda.
• Vuelva a la página original haciendo clic en "Investigación" en el encabezado. La página ahora funciona y los paneles son plegables.

¿Cómo depuro esto? No hay solicitudes de red que 404 ni nada, así que no entiendo lo que está sucediendo. Las versiones locales son las siguientes, pero las compilaciones ocurren en 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

En nuestro caso, teníamos una página como exportación predeterminada, luego también teníamos una exportación con nombre en el archivo de página. Tan pronto como algo hizo referencia a la exportación nombrada desde fuera del archivo de página, se confundió mucho.

La solución fue eliminar todas las exportaciones de las páginas, excepto la exportación del componente de página real predeterminada.

@thekevinbrown ¿El error que veía era intermitente? ¿O sucedió todo el tiempo?

@Distracción cada vez que iniciaba o actualizaba la página con el problema. Si comenzaste en una página diferente, o navegaste fuera de la página a una que funcionaba, entonces regresaste, estaba bien. Entonces, básicamente, la hidratación inicial falla en este caso, mientras que si puede llevar al usuario a una página diferente donde funciona la hidratación, entonces la descarga y visualización de la página rota funciona.

Definitivamente hubiera sido mejor como un claro error de compilación en lugar de un oscuro error de tiempo de ejecución si eso es posible.

@thekevinbrown, así que creo que su problema no está relacionado con este problema (que es un error intermitente que nadie ha podido reproducir de manera confiable), así que creo que, aunque está viendo el mismo error, la causa es diferente (y afortunadamente ha lo arregló fácilmente).

Encontré este error en nuestro sitio de producción y la actualización a la última versión de Gatsby (lanzada hace solo 2 días) solucionó el error de Safari

Actualizado a la última versión de Gatsby. El problema aún ocurre

Nunca he experimentado esto antes. De repente sucede todo el tiempo. Solo en producción 😢
Esto sucedió después de una actualización hace 20 horas. Actualizamos las dependencias con bastante regularidad.
Básicamente, el proyecto no funciona y no tengo idea de cómo hacerlo funcionar nuevamente.

Intenté revertir las actualizaciones a lo que eran hace 20 horas. No ayudó.
Volver a hace 8 días tampoco ayudó.

Aquí está el proyecto con actualizaciones más recientes: https://vermehrungch-4utm3ymcd.now.sh/Vermehrung/
Y aquí el último en funcionamiento de hace 8 días: https://vermehrungch-9l709pu84.now.sh/Vermehrung/

Revertir las dependencias de Gatsby a lo que eran hace 9 días hizo que una nueva compilación funcione nuevamente 😆

Ahora intentaremos aislar qué causa la dependencia de gatsby.

Ok, en nuestro caso:

• Definitivamente Gatsby mismo es la causa
• versiones hasta 2.20.36 funcionan
• v2.21.2 y v2.21.3 tienen el error anterior (había probado v2.21.17 antes, el mismo error)
• v2.21.0 tiene un error diferente:
  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)

Actualización: el error todavía ocurre en gatsby v2.21.19

@barbalex, ¿ podrías compartir tu sitio con nosotros? Si es privado, envíe un correo electrónico a [email protected].

Recibo este error en su sitio cuando lo depuro

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

El sitio es:

• https://vermehrung.ch
• https://github.com/barbalex/vermehrung
• incluso puede iniciar sesión con la contraseña enviada por correo

El sitio está en desarrollo. Así que incluso puedes editar datos.

Recibimos los mismos mensajes de error en Sentry de forma recurrente:

Estamos usando la versión "2.21.22" de gatsby.

Encontré el mismo problema y lo solucioné rebajando a v2.20.36, que se menciona anteriormente.

Ok, en nuestro caso:

• Definitivamente Gatsby mismo es la causa
• versiones hasta 2.20.36 funcionan
• v2.21.2 y v2.21.3 tienen el error anterior (había probado v2.21.17 antes, el mismo error)

Me encontré con esto nuevamente en un proyecto diferente que tenía la versión 2.21.12. Esto es _realmente_ malo, ya que solo ocurre en producción. Priorice este error.

Estamos viendo esto en producción en https://www.voteamerica.com/. Ocurre principalmente en Mobile Safari, pero también lo estamos viendo en Android Chrome, escritorio Safari, escritorio Chrome y otros. Actualmente estamos usando Gatsby 2.21.40, pero también vimos el problema en 2.20.12

Tengo el mismo problema para la única página que se eliminó recientemente. https://intergiro.com/legal no muestra la página 404 personalizada como se esperaba (escritorio Chrome, Gatsby 2.20.8). También ocurre solo en producción.

En mi caso, el comentario de @Kanuny resolvió indirectamente mi problema. Redirigí accidentalmente los datos de la página JSON a un archivo HTML cuando publicLoader.loadPage intentaba recuperarlo. Después de corregir las redirecciones, los datos de la página JSON se cargan correctamente y todo funciona como de costumbre.

El insecto desapareció de repente de nuevo. Parece que podría estar vinculado a la caché o algo así

El error sigue ocurriendo en la versión 2.22.12 en las últimas versiones de Firefox y Chrome también.

¡Por favor, arreglalo!

¡Por favor, arreglalo!

@SoldierCorp, por favor lea acerca de lo que es Open Source y tal vez intente arreglarlo usted mismo.

@antoinerousseau también se trata de ayudarse unos a otros, donde los que necesitan ayuda, la piden y los que saben cómo, la ofrecen. Entonces creo que tu comentario está fuera de lugar.

@andrzejwp sí, se trata de ayudarse unos a otros, no de publicar comentarios mandones como "¡por favor, arréglalo!" sin información útil para solucionar el problema, mientras se notifica a 25 personas después de este problema.

Otros han comentado con información detallada sobre cómo les afecta, lo cual es necesario para que los contribuyentes los ayuden y, con suerte, solucionen problemas de OSS.

@antoinerousseau No hay más información útil relacionada con este porque no hay más información proporcionada por el problema, así que simplemente sucede, así que escribí que para evitar repetir lo mismo que otras personas están escribiendo porque es lo mismo al final hasta el ultima versión.

Es solo para hacerle saber a Gatsby que más personas todavía están experimentando el problema y que aún no se ha solucionado.

Lo siento si eso te molesta, pero soy un usuario habitual que está usando el marco y no tengo tiempo para solucionar el problema por mí mismo.

En mi caso, esto solo ocurría al prefijar rutas, ya que estoy intentando usar gatsby-plugin-ipfs (Ejecutar gatsby build --prefix-paths && gatsby serve produciría un "Error / recursos de página para / no encontrados. No renderizar React" para cada página).
Sin embargo, en mi página index.jsx no estaba ejecutando ninguna consulta de página, pero tenía un componente que contenía una staticQuery, del gancho useStaticQuery.
Si comentaba este componente y lo reconstruía, el error desaparecería.
Curiosamente, si luego quito los comentarios de este componente y lo reconstruyo nuevamente (para que el sitio vuelva al estado inicial), entonces funcionaría bien y no encontraría el error "Error / recursos de página para / no encontrado. No se muestra React", sugiriendo que el caché de compilación contiene algo importante?

Entonces, mis pensamientos (aproximados) de por qué podría ocurrir esto son:

• ¿Problemas con la página de índice que contiene una consulta estática, pero no una consulta de página?
• Problemas con el orden del proceso de construcción (ya que el almacenamiento en caché puede modificar los resultados).
• Potencialmente un problema con run static queries o Generating image thumbnails en el proceso de compilación, ya que estos son los únicos pasos que parecen omitirse gracias al caché.

Redirigí accidentalmente los datos de la página JSON a un archivo HTML

Situación similar aquí. Esencialmente, una expresión regular de directiva nginx location también coincidía con /page-data/items/page-data.json cuando no debería haberlo hecho. Agregar un ^ al comienzo de la expresión regular evitó la coincidencia no deseada.

Estamos viendo esto en producción en https://www.voteamerica.com/. Ocurre principalmente en Mobile Safari, pero también lo estamos viendo en Android Chrome, escritorio Safari, escritorio Chrome y otros. Actualmente estamos usando Gatsby 2.21.40, pero también vimos el problema en 2.20.12

También enfrenta el mismo problema.

Hola equipo de Gatsby, hola a todos. ¿Sería posible especificar los errores devueltos en loadPage que parece ser la fuente de los diversos errores que surgieron en este problema?

Refiérase a la función: https://github.com/gatsbyjs/gatsby/blob/030d927cddbdc64f8d93d409a5ada7442d5e62bf/packages/gatsby/cache-dir/loader.js#L179 -L242

Tengo entendido que esta función intenta cargar app-data.json , page-data.json y luego los componentes JS mismos, por lo que es muy propenso a problemas de red, problemas de configuración del servidor, problemas de desarrollo, problemas de configuración ... Al especificar el mensaje de error, sería más fácil solucionar los problemas subyacentes.

(Como referencia: la última aparición de este problema en nuestro sitio web fue debido a una importación circular)

Intenté de nuevo con v2.23.12. Mismo resultado: https://vermehrungch-1j64x2olp.vercel.app/Vermehrung

Para nosotros parece absolutamente sistemático ya que todas las versiones anteriores a la 2.20.36. En cada una de las cinco aplicaciones creadas con gatsby. Así que desde entonces se nos ha bloqueado la actualización.

Lo cual está empezando a convertirse en un problema. Por ejemplo, no podemos usar ninguna biblioteca que use core-js en v3 (https://github.com/gatsbyjs/gatsby/issues/15601). Ese problema ya se ha resuelto, si _podríamos_ actualizar.

Si hay alguna forma en que pueda ayudar con información / pruebas / lo que sea, con mucho gusto lo haría.

@barbalex Tiene el siguiente error en su aplicación:

Definitivamente deberíamos mostrar este error. Siéntase libre de agregar un PR, no tengo suficiente ancho de banda para hacer este cajero automático.

Parece que este problema en nuestro caso es causado por react-contextmenu cuando esa lib se usa en el lado del servidor: https://github.com/vkbansal/react-contextmenu/issues/284 , que parece activarse durante el proceso de compilación.

@wardpeet

Siéntase libre de agregar un PR, no tengo suficiente ancho de banda para hacer este cajero automático

Lamento decirlo, parece que no tengo suficientes celdas grises para eso 😢
¿Quizás @ b4stien lo hace?

El problema aún persiste en la versión 2.23.21

No tengo una solución general para esto, pero solo quería que se supiera que tuve este problema esta mañana por primera vez.

Y me las arreglé para "arreglarlo".

El sitio está alojado en AWS a través de un proveedor llamado "Cloudways".

Como prueba inicial, implementé el sitio en Netlify y todo funcionó bien.

Después de investigar un poco, parecía haber un problema de caché del lado del servidor al usar algo llamado "Varnish".

Primero intenté "purgarlo" y no pasó nada, pero desactivarlo y reactivarlo funcionó.

Este sitio ha existido bien durante aproximadamente 18 meses en este entorno con actualizaciones periódicas, y esta era la primera vez que me encontraba con este problema.

Recientemente actualicé a:
Versión de Gatsby CLI: 2.12.59

No estoy seguro de si esto podría haber tenido algún efecto, pero es el único cambio en el que puedo pensar, a menos que, por supuesto, haya un cambio en el lado del alojamiento.

Espero que esto ayude a alguien por ahí 🤷

EDITAR:

El problema volvió a los 5 minutos cuando volví a habilitar la caché de "barniz".

He desactivado esta función por ahora.

En nuestro caso, todas las páginas creadas a partir de la carpeta /pages funcionan, pero el resto creado por createPages no se rehidrata y reacciona.
Estamos experimentando este problema tanto en local como en CI.

en nuestro caso, todas las páginas creadas con createPages , porque estamos usando la internacionalización con el prefijo /${locale}/ cada página.

en nuestro caso, todas las páginas creadas con createPages , porque estamos usando la internacionalización con el prefijo /${locale}/ cada página.

encontraste una solución para esto? también tenemos esta configuración con muchas configuraciones regionales

@kdichev No, no encontré solución. Esperando que el equipo de Gatsby arregle esto a nivel de biblioteca.

Todavía no estoy seguro de dónde está el problema, con mucho gusto haría un PR para esto, pero me gustaría si llegamos y encontramos dónde está el problema subyacente.

Hola chicos, estoy enfrentando este problema en producción con IE11.

"gatsby": "^ 2.23.11"

También frente a un resultado en blanco (sin hidratación) de todas las páginas en IE11.
Recursos de página para / no encontrados. No renderizar reaccionar

Gatsby v2.24.2

EDITAR: volví a la versión de funcionamiento anterior v2.22.11. ie11 funcionó en esa confirmación y, con razón, también funcionó ahora, aunque solo cuando mantuve package-lock.json y npm ci. De alguna manera, no creo que esto sea Gatsby equivocado, por lo que estoy enumerando algunos posibles cambios posteriores que pueden ser relevantes:
(versión de trabajo -> versión de compilación fallida)
los grandes que son probables candidatos para solo fallas ie11:
@ babel / core 7.10.0 -> 7.10.5
@ core / js 2.6.11 -> 3.6.5
gatsby-legacy-polyfills nuevo dep 0.0.2

otros menos probables:
@ graphql-tools / schema nueva dep 6.0.14
@ graphql-tools / utils nueva dep 6.0.14
y luego mi paciencia de tamizar todo rojo-> todo verde en la herramienta de diferencia vscode se agotó

Otras cosas a tener en cuenta: reproduje el error con gatsby build && gatsby serve -H 0.0.0.0, por lo que descarta cualquier cosa relacionada con el entorno del servidor.

EDITAR 2: La salida de compilación de la compilación fauly v2.24.2 reportada por primera vez en mi publicación pasó de 10mb a 30mb. Tiene alrededor de 20 versiones de app- {hash} .js, 2 de commons- {hash} .js y varios números de pages.js. Parece que no son los mismos archivos y están fechados para coincidir con las versiones anteriores. Así que parece que gatsby build de alguna manera se apoderó de todas las versiones antiguas disponibles y las arrojó a / public.

¿Alguien puede compartir un repositorio?

@roffelsaurus, ¿puedes probar 2.23.22?
para nosotros 2.24.2 está fallando en las pruebas ci / cd cypress.

¿Alguien puede compartir un repositorio?

podemos compartir nuestro repositorio y vars de forma privada, si está bien para usted, envíeme un correo electrónico a konstantin. [email protected] y te

@wardpeet puede probar este problema en el repositorio que le di acceso relacionado con el problema # 25766

En mi caso, el problema estaba relacionado con el pedido import y la forma en que se manejan algunas bibliotecas (a saber, react-leaflet ) en un entorno de renderizado del lado del servidor. Tuvimos un complemento de folleto importado antes que el propio folleto, lo que causó el problema más adelante. Pude arreglarlo bastante rápido una vez que supe dónde buscar.

Sin embargo, creo que el mensaje de error que generó ( page resources for / not found. Not rendering React ) fue increíblemente confuso y la falta de detalles y otros errores fue el problema principal, ya que tuve que cavar bastante profundamente para saber qué significa.

Para cualquier otra persona que tenga este problema: ¿Cómo lo encontré? Buen punto de ruptura y depuración en cromo. gatsby build && gatsby serve permitió ver el entorno de producción localmente con todos los mapas de origen en su lugar. Pude depurar qué fragmento y luego el componente no se carga y se mete con las importaciones en el interior. Fue un proceso bastante lento, así que tenga paciencia ya que volverá a cargar la página una y otra vez. Busque el nombre de su fragmento (en mi caso fue component---src-pages-index-js ) y la importación que se le asignó. Ingrese y observe sus dependencias, ya que una de ellas fallará. Creo que en cada caso será diferente, por eso no puedes encontrar una buena solución en ningún lado. Los mapas de origen fueron útiles, ya que me mostraron más que una serie de promesas genéricas en la matriz.

Este no es el núcleo del tema, pero dejaré detalles de lo que descubrí a continuación. Sin embargo, tenga en cuenta que a

Entonces, así es como era originalmente:

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

y así es como se ve ahora:

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

Por supuesto, eso es un error de nuestra parte, ya que cualquier complemento generalmente debería ir después de la biblioteca a la que se está conectando. Dado que react-leaflet (creo) cambia un poco el orden de carga al ejecutar la depuración, el problema no fue visible durante el desarrollo.

Acabo de depurar Uncaught (in promise) Error: page resources for /app/ not found. Not rendering React en mi aplicación. En mi caso, / app / es una ruta solo para clientes que contiene una aplicación de reacción. No tuve problemas en gatsby develop , pero recibí este error al ejecutar gatsby serve y también en la compilación de producción. No se informaron errores de compilación.

Resulta que el problema fue con react-contextmenu (https://github.com/vkbansal/react-contextmenu/issues/284) con el que @barbalex también se encontró. No sé si esto es "culpa" de react-contextmenu ... parece que la biblioteca está buscando mantenedores y el autor probablemente se centró en la implementación del lado del cliente en lugar del lado del servidor. No sé si hay algo que Gatsby pueda hacer para facilitar la depuración, el mensaje de error no fue muy útil.

@rgembalik , la forma en que depuré esto fue eliminando todos los componentes del componente de mi aplicación y luego volviéndolos a agregar uno por uno hasta que encontré el componente que estaba rompiendo la compilación.

Para mí, ni siquiera puedo replicar, solo veo muchos de estos errores en los informes de errores de centinela. así que no estoy seguro de cómo me daré cuenta

Estamos obteniendo muchos de estos en Sentry con estos errores también para todo tipo de páginas además de "/", que tampoco se han podido replicar. Alojado en Netlify. Sospecho que puede tener algo que ver con las sesiones activas durante las implementaciones, pero es difícil de verificar.

@wardpeet parece que hay muchas causas potenciales diferentes que desencadenan este mismo error. Para nosotros, solo vemos estos errores en nuestro registro de Sentry y nunca hemos podido reproducirlos. ¿Sería posible incluir más información con el error, o agregar errores múltiples y más granulares para que todos tengamos algo más en lo que hacer para tratar de encontrar la causa?

Acabo de recibir este error en https://www.gatsbyjs.com/ terminando con una página en blanco

Puedo confirmar que en la primera carga de la página inicial vi este error en gatsbyjs.com

Descubrí que Gatsby tiene una forma particular de manejar las rutas de URL con barras al final. No se si esto puede ayudar

También estoy teniendo este problema.

No puedo compartir el repositorio, pero si accedes a esta página puedes ver que carga un SVG correctamente. Pero, si voy a una ruta que no existe, por ejemplo https://rocketseat.com.br/test , muestra una versión desactualizada del código (que todavía usa gatsby-image lugar de un SVG) y muestra me este mensaje en la consola:

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

Estoy usando [email protected]

_editar: no sé por qué, pero después de agregar mi problema aquí, el problema de la imagen se resolvió, pero sigo recibiendo el mismo error en la consola de la página_

Es difícil para mí replicar, solo veo un montón de estos errores en los informes de errores de centinela

@theskillwithin - lo mismo. Miles de ellos en Sentry.

Tengo el mismo problema. Muy extraño. Parece que hay varias causas que desencadenan este error.

También estamos viendo que este error ocurre en una variedad de navegadores y en una variedad de páginas. Parece que no puedo relacionar nuestra situación con ninguna de las posibles causas mencionadas anteriormente. Y también parece que no puedo replicar en el desarrollo, solo sucede en nuestro sitio web implementado.

Tengo el mismo problema. no puedo replicar pero toneladas de estos errores en centinela. también variedad de navegadores
gatsby versión 2.24.3

Estos se informan con frecuencia en un sitio de producción donde también estoy usando Sentry. Incapaz de replicarme. A mi modo de ver, necesitamos mejores informes. Lo extraño de esto es que, de hecho, encuentra los datos de la página:

Dado que está recibiendo un estado 200, y AFAICT, el json no está mal formado, supongo que fetchPageDataJson() está devolviendo una respuesta exitosa:
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L137 -L151

Dado que todo parece tener éxito, el siguiente punto de falla que puedo ver sería cargar el componente en sí:
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

Quizás haya un problema en los async-requires que se están escribiendo. Sin embargo, me imagino que están bien, ya que serán manejados por Webpack, y el problema parece ser intermitente. Si hubiera un problema con la forma en que se escribe ese archivo, haría que la compilación fracasara.

Si se tratara de algún tipo de problema de sintaxis en algún lugar del módulo que se está importando, imagino que fallaría el 100% del tiempo. Quizás hay algo que se está usando en un módulo que no es compatible con cualquier dispositivo / navegador que esté cargando dicho módulo. Es difícil de decir, seguro, ya que el error específico se oculta.

Lo que creo que necesitamos es el cargador de componentes para _no_ comerse el error que se genera.

Tener Promise.resolve() allí cuando un fragmento no existe en asyncRequires significa que el error arrojado tendría sentido. Ese error también se lanzaría en cada visita a esa página ... por lo que sería fácil rastrear la causa.

Devolver null en el bloque catch significa que el error arrojado no tiene sentido. Se encontró el módulo, pero se produjo un error durante la importación dinámica. ¿No devuelve el paquete web un error en el bloque catch() de una importación dinámica? Si no es así, entonces tal vez este sea un problema que debería abordarse con Webpack. Sé que si ejecuto un import() incorrecto de devtools, se informa un error ... si se informa o no un error basado en la incapacidad / falla para analizar el javascript que se está importando es otra pregunta, y tomaría algunas pruebas adicionales con algún código que _ sé_ no funcionarán en ciertos navegadores.

@wardpeet mencionaste mejores informes de errores anteriormente . ¿Está en proceso o se necesita ayuda?

Con respecto a la compatibilidad del navegador, veo estos errores generados principalmente por dispositivos móviles.

Pero también he visto estos errores generados en MacOS X usando Safari y Windows 10 usando Chrome.

Un punto en común es que el tráfico generalmente parece provenir de Facebook o Google. Pero eso puede ser solo una coincidencia, ya que son los que impulsan la mayor parte de nuestro tráfico.

_NOTA: Este sitio con el que estoy trabajando en realidad usa [email protected] , por lo que el código al que he vinculado está en diferentes lugares, pero la lógica en sí no parece haber cambiado. Todavía está haciendo lo mismo, y los puntos potenciales de falla que he identificado parecen ser los mismos.

[email protected]

También veo el error con poca frecuencia en bugsnag. No tengo claro si la página se está mostrando o no. Aquí está la pila de bugsnag si es de alguna ayuda @wardpeet Es interesante que en este caso parece haberlo intentado varias veces. Tenga en cuenta que esta es una de las muchas páginas / webinar / blah ... en las que usamos createPage () pero, por supuesto, si trato de GET / page-data / ... como se muestra en la foto, funciona para mí.

Agregaré información adicional al error registrado, así que, con suerte, podemos encontrar el problema.

Estoy experimentando el mismo problema con una página que originó otro error publicado en https://github.com/gatsbyjs/gatsby/issues/26706

En mi caso, sucede en (al menos) escritorio Chrome, y solo sucede la primera vez que cargo la página, si presiono actualizar, todo se procesa como se esperaba

Luego, si trato de replicar esa primera vez, incluso con el modo incognito y tratando de borrar cada caché que se me ocurre, no puedo (a veces he podido, aunque muy al azar), hasta después de un tiempo ( unos días) visito la url y encuentro el mismo error (que desaparece después de actualizar de nuevo)

Si trato de replicarlo con el mismo repositorio mínimo que usé para el problema vinculado anterior, no puedo ver los mismos errores (al menos no las veces que lo he intentado ahora)

El error es (en este caso) visible debido a que no se está creando la cuadrícula de mampostería, que en mi caso destruye la página a menos que el usuario piense en actualizar la página (sospecho que no)

En realidad, se siente tan aleatorio que lo he estado viendo durante algunas semanas, pero siempre pensé que esto era algo con mi PC.

Ejecuté npm auidit fix y el problema se solucionó.

¡Siguiendo! También tengo el mismo problema

Hola,

También tenemos este problema solo en producción. Reproducimos este error el 100% del tiempo de URL específicas. Veamos la estructura de árbol de nuestro directorio public :

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

Cuando ingresamos estas URL https://domain.com/usages/brainstorming funciona perfectamente, https://domain.com/usages/seminaries también. Si ingresamos una URL desconocida como https://domain.com/doesnotexist tenemos legítimamente la página 404, pero si intentamos llegar a una URL que coincida con una carpeta real en el árbol, como https://domain.com/usages , tenemos esta página en blanco y este error.

¿Eso puede sonarle una campana?

Mejor

@guillaumepotier, ¿también

Creo que podría deberse a encabezados de respuesta defectuosos.

@ daydream05 sí, de hecho, estamos usando nginx. Vimos en nuestros registros unos 304 encabezados de contenido No modificado y, a veces, 200 respuestas.

usando el bucket de AWS S3

Lo mismo aquí, alojamiento en AWS S3 (con CloudFront CDN).

Ejecuté npm audit fix y el problema se solucionó.

Interesante @ liuuuk311. Lo probé en nuestro proyecto y posiblemente también nos haya resuelto el problema. El tiempo lo dirá, pero hasta ahora después de 48 horas no hay incidencias en nuestros registros.

Editar: 5 días después, todavía no hay ocurrencias ...

Editar: 10 días después y ha ocurrido varias veces nuevamente, lamento informar. Ejecutar npm audit fix en sí mismo no parece resolver el problema.

@wardpeet algunos datos adicionales de bugsnag que pueden ayudar a diagnosticar ...

Según estos, parece que los archivos page-data.json se están cargando correctamente ...

• Desde que me encontré con esto hoy, chocaré * y miraré aquí.

En mi caso, solucioné el problema al cargar polyfill.io lib en la página

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

@pedrofsantoscom, por favor explique cómo el script cargado estáticamente resuelve un problema para gatsby.js.

Ayer tuve el mismo problema. El borrado de la caché lo solucionó localmente para el usuario actual. Así que limpiamos el caché en Cloudflare y ahora ya no recibimos ningún informe.
Borrar caché fue nuestra solución

No usamos Cloudflare, usamos AWS Cloudfront CDN y se invalida después de cada implementación. Experimenté el error localmente al ejecutar el servidor web local con https con el primer intento de ejecución después de que se inicie el servidor web y también en algunas recargas de página consiguientes, pero no siempre. No veo ningún patrón. Solo sucede de vez en cuando.

No usamos Cloudflare, usamos AWS Cloudfront CDN y se invalida después de cada implementación. Experimenté el error localmente al ejecutar el servidor web local con https con el primer intento de ejecución después de que se inicie el servidor web y también en algunas recargas de página consiguientes, pero no siempre. No veo ningún patrón. Solo sucede de vez en cuando.

Esa fue la solución para nosotros. Cuando borramos el caché, los errores por hora se redujeron rápidamente y al menos no obtuvimos el mismo error en bugsnag. De hecho, este es un error extraño.

Recibí el mismo mensaje de error pero solo en Internet Explorer. Todos los demás navegadores no mostraron este tipo de mensaje de error.

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

Rastreé el problema hasta una importación que hice en mis componentes de reacción. En algunos casos, tuve dependencias de https://sap.github.io/ui5-webcomponents/ . Una vez que eliminé esas dependencias, el problema desapareció. No puedo explicar cuál es la causa raíz real, pero quiero señalar que las dependencias en sus controles de reacción pueden causar este problema.

@Chaosbohne realmente no puede discutir con eso, pero incluso diría que es un problema de gatsby.js se ocupará de la gestión de dependencias y la seguridad, y en el primer paso eliminará ^ de todas las versiones de dependencia / devDependency, se podría evitar toda una gama de problemas.

Puedo decir que este problema no depende del navegador. Lo he visto en Chrome y Safari según los registros de Sentry, y en Chrome 85, 86 localmente en mi mac.

Ninguna de las soluciones funciona. @KyleAMathews debido a este problema estamos perdiendo negocios, dentro de 3-4 días ocurre este problema y no podemos averiguar la causa raíz. Ayúdenos a encontrar la solución a este problema.

@ R3coN ¿Intentaste reconstruir tu sitio web? Cuando eso nos sucedió, básicamente lo intentamos nuevamente (eso fue hace un tiempo, no puedo recordar por qué se solucionó)

@ R3coN, si puede ayudar, aquí están las versiones de paquetes que usamos que funcionan bien:

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

@ shide1989 sí, esa es la única forma de solucionarlo, reconstruyendo el sitio web nuevamente. Pero la reconstrucción también soluciona el problema durante 2-3 días y luego vuelve a aparecer este problema. Estamos usando la versión de Gatsby CLI: 2.12.67 y la versión de Gatsby: 2.24.47, como ha mencionado, la versión 2.20.36 de gatsby está funcionando bien para usted, probaremos suerte al degradar la versión de gatsby.

@ shide1989 Gracias por el comentario. Pero degradar la versión me arroja este error ->

WebpackError: No se pudo recuperar el resultado de esta StaticQuery.

Que estaba funcionando en la versión anterior 2.24.47.

Lamento escuchar eso, tal vez le falte un literal de plantilla con etiqueta graphql en el mismo archivo donde se usa el gancho useStaticQuery para extraer consultas en el momento de la compilación. (como se describe aquí: https://github.com/gatsbyjs/gatsby/issues/24526)

de todos modos buena suerte con eso

Pero te dije que el mismo código funcionaba para gatsby 2.24.47.

@ R3coN este problema también puede deberse a un almacenamiento en caché estático incorrecto. Si está utilizando nginx o s3 para su servidor y no invalida su page-data.json, sus StaticQueries se romperán cada vez que cambie sus datos.

Tuve este problema y resultó que estaba almacenando en caché todo el archivo page-data.json. No deberían serlo. Deben ser revalidados cada solicitud

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

@ daydream05 Gracias por el comentario. Sí, estoy usando S3 con CloudFront. ¿Tiene alguna idea de cómo lograr esto con Cloudfront?

@ daydream05 Ya tengo cache-control: 'public, max-age = 0, must-revalidate' agregado a page-data.json y app-data.json, lo que significa que estas páginas no se almacenan en caché.

También veo esto en páginas que no existen (que deberían cargar e hidratar la página 404).

Localmente, mis compilaciones de desarrollo y producción funcionan sin este error, y cuando inserto un console.log durante la verificación que arroja ese error en la producción construida app-[hash].js , puedo ver que el page objeto existe e incluye page.componentChunkName: ""component---src-pages-404-js" como espero que debería.

Sin embargo, cuando la aplicación se implementa en la nube de gatsby, el error ocurre en cada carga de una página que no existe. La página SSR'd 404 se muestra en el navegador, pero luego aparece el error, por lo que React nunca se ejecuta en el navegador. Cuando la página 404 se carga directamente (visitando la ruta /404 ) funciona bien, sin errores.

Esto es difícil de diagnosticar porque no he podido replicarlo localmente hasta ahora.

Usando la última versión: "gatsby": "^2.24.91"

Simplemente publique esto aquí para permitir que otros usen react-md para arreglar rápidamente su sitio, o esperando que esto pueda ayudar de todos modos a solucionar este problema en Gatsby.

Tuve el mismo error en uno de mis proyectos, donde estaba usando react-md
Después de eliminar todos los componentes, pude deshacerme del problema.

Como tuve que implementar para prod cada vez para probar esto, no he logrado identificar qué componente específico tiene este problema, pero lo he reducido a.

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

Actualizaré la publicación de mi blog sobre este tema si tengo tiempo para profundizar más.

Con respecto a las páginas 404, puedo confirmar el problema de @aMoniker ya que me está sucediendo el mismo patrón de comportamiento.

A nivel local, tanto las compilaciones de desarrollo como las de producción funcionan bien con la página 404 , pero cuando se implementan en Gatsby Cloud, obtengo el problema en todas las páginas desconocidas excepto en la ruta /404 real.

También encontré este error y lo solucioné borrando la memoria caché del navegador. Sin embargo, sería bueno encontrar una solución que no requiera eso, ya que no podemos forzar a todos nuestros usos a hacer esto.

@ dejavu1987 no estamos usando react-md en proyectos que experimentan este problema.

@MaciekBaron Había reproducido un error localmente al borrar el caché del navegador varias veces y volver a cargar la página después de cada borrado.

Esto parece ser un problema de almacenamiento en caché como mencioné anteriormente. Si los encabezados de la caché están configurados correctamente, el problema podría estar relacionado con los trabajadores del servicio.

¿Quizás darle una oportunidad a este complemento?
https://www.npmjs.com/package/gatsby-plugin-remove-serviceworker

Oye, también me encuentro con este problema. En el desarrollo, todo funciona bien, pero cuando ejecuto gatsby build y despliegue el directorio público en mi proveedor de alojamiento web, una página no funciona debido a este mensaje de error.

Tenía mucha curiosidad y busqué en el directorio público de datos de páginas. Descubrí que existe el directorio de páginas específico, pero no estaba en minúscula, sino que el directorio estaba en mayúscula. Ese fue el problema. Recibí el mensaje de error.

Después de eso, lo cambié a letra pequeña al principio y funciona bien en prod. Creo que esto ocurre porque cambié el nombre de la página anteriormente y tal vez algo esté almacenado en caché aquí.

También me encuentro con este problema. Encontré un método para solucionar este problema. Pero creo que no ha solucionado el verdadero problema.

Ahora, déjame explicarte cómo solucionarlo.

Este problema se encontró en el entorno de prueba o producción, como dice todo lo anterior, no se reproducirá en el desarrollo. Incluso en pruebas o producción, no sucedió siempre. Y descubrí que todos los scripts se precargaron y ejecutaron de forma asincrónica. Entonces supongo que puede ser causado por la orden ejecutiva de los guiones.

A medida que reduzco la velocidad de la red en la red, por ejemplo, configurada como 3G fast , el problema casi ocurre siempre. Esto confirmó mi suposición.

Para validar mi suposición, he cambiado el proceso de renderizado HTML en gatsby-ssr.js para configurar todos los scripts sin "async" , de la siguiente manera:

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

Felizmente, funciona.

Aunque esta forma puede ayudar a solucionar el problema, no creo que sea una buena forma de hacerlo. Parece violar la función de gatsby. ¿El script se ejecuta de forma asincrónica y está diseñado para ser así?

Con suerte, esta forma también puede resolver todos sus problemas.

Este problema se encontró en el entorno de prueba o producción, como dice todo lo anterior, no se reproducirá en el desarrollo. Incluso en pruebas o producción, no sucedió siempre. Y descubrí que todos los scripts se precargaron y ejecutaron de forma asincrónica. Entonces supongo que puede ser causado por la orden ejecutiva de los guiones.

Aunque esta forma puede ayudar a solucionar el problema, no creo que sea una buena forma de hacerlo. Parece violar la función de gatsby. ¿El script se ejecuta de forma asincrónica y está diseñado para ser así?

Creo que tienes razón, tuve este problema volviendo por extrañas razones.
El último fue salvaje, pero cuando lo relaciono con tu respuesta, tiene sentido.

Entonces, recientemente agregué un componente de ícono de fuente a mi componente de diseño y reprodujo este problema.
Un punto importante a tener en cuenta es que los íconos de fuentes se han utilizado en otros componentes anidados profundos todo este tiempo, y nunca causó el problema, solo cuando está en el nivel de diseño, que es el primer componente llamado desde cualquier componente de la página.

Podría estar equivocado, pero este podría ser un buen escenario para descubrir la causa real.

@ dejavu1987 Estoy de acuerdo contigo. Quizás haya dado un buen escenario para descubrir la causa real.

Además, me pregunto si es adecuado cargar y ejecutar los scripts con async , ya que el paquete web divide los códigos en diferentes partes, pero las partes pueden tener dependencias.

El problema principal parece ser que Gatsby traga errores durante la carga de la página y solo informa el mensaje page resources for / not found. Not rendering React muy genérico, razón por la cual hay tantas causas potenciales diferentes informadas en este hilo.

Mi problema resultó ser que Mobx 5 no es compatible con IE11, y aunque Mobx proporciona un buen mensaje de error para esto, todo lo que obtuve fue el mensaje "Recursos de página no encontrados" de Gatsby, que era bastante engañoso.

Humildemente sugeriría como resolución de este problema informar el mensaje de error original que hizo que fallara la carga de la página. @wardpeet

Lo que me solucionó es que tenía S3 configurado para devolver un 200 en la página 404. Cuando lo cambié para devolver un código de estado 404, funcionó.

Sí, también encontré esto. Sin embargo, mi problema era más amplio ... Estaba almacenando en caché incorrectamente los resultados de Cloudfront 404. La razón por la que obtenía resultados 404 entre Cloudfront y S3 es que la implementación en S3 a través de CodePipeline creo que descomprime el archivo ZIP Build Artifact, pero no lo hace en ningún orden en particular. Entonces, durante unos minutos, puede tener nuevos archivos .HTML que apuntan a nuevos archivos .JS (con nuevos hash) que aún no están disponibles. Cualquier cosa que maneje el almacenamiento en caché de sus archivos de activos con hash no debe almacenar en caché los resultados 404, ya que esto solo se puede corregir vaciando su caché de CDN.

Por cierto, ¿alguien ha descubierto cómo asegurarse de que los archivos HTML se implementen en S3 al final?

David
https://ewebinar.com

El 21 de octubre de 2020, a las 12:40 p.m., Vince P. [email protected] escribió:

@ R3coN https://github.com/R3coN este problema también puede deberse a un almacenamiento en caché estático incorrecto. Si está utilizando nginx o s3 para su servidor y no invalida su page-data.json, sus StaticQueries se romperán cada vez que cambie sus datos.

Tuve este problema y resultó que estaba almacenando en caché todo el archivo page-data.json. No deberían serlo. Deben ser revalidados cada solicitud

https://www.gatsbyjs.com/docs/caching/ https://www.gatsbyjs.com/docs/caching/
-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/gatsbyjs/gatsby/issues/19618#issuecomment-713298516 , o cancele la suscripción https://github.com/notifications/unsubscribe-auth/AA3SHT55MXZTXQUAXH5ZUY3SLZQ4VANCB5FSIKMQ4VANCN5 .

Puedo agregar que había reproducido un problema con Chrome Lighthouse Audit en pruebas móviles, con pruebas PWA y sin ellas. Estoy seguro de que las pruebas móviles utilizan límites de red y cpu, por lo que los scripts asíncronos se cargan fuera de orden, o uno de los 30 fallando ... podría ser una situación bastante frecuente.

Estoy trabajando con 3d, e incluso en localhost con webpack y gatsby.js , recargar la página a menudo da como resultado solicitudes de red fallidas para el modelo estático gtlf archivos. Uno de ellos ha fallado: todas las aplicaciones están dañadas (si no se estableció ningún ErrorBoundary).

Supongo que aquí podría haber el mismo patrón, pero sin un manejo adecuado de errores.

Estoy usando S3 y CloudFront para producción. Tuve un problema similar, pero en mi caso recibí el error Can't render React en la consola solo en Cloudfront. Esto comenzó a suceder después de cambiar archivos en el S3 de producción. Para mi sorpresa, el problema se resolvió después de volver a ejecutar el faro para el origen de la producción.

Esto solo estaba sucediendo en mi dispositivo en modo normal. En mi caso, limpiar todo el caché, las cookies, el almacenamiento local, el almacenamiento de sesiones y los trabajadores de servicio no ayudaron antes.

Entonces, si perfila el origen de su producción con Lighthouse y se cambiaron los archivos, este problema también puede ocurrir (en mi caso, lo fue)

Mi punto es que puedo reproducirlo con Lighthouse prácticamente 1 de 10, y la última implementación fue hace mucho tiempo.

No creo que Gatsby pueda resolver este problema, porque esto les está pasando a todos, pero la razón es diferente. Recibo páginas en blanco con demasiada frecuencia o cada vez que cambio algo en la página de gatsby del backend se queda en blanco y arroja un error, y ese error también es diferente cada vez. Creo que tenemos que dejar de usar gatsby y cambiar a otro marco confiable.

Podría corregir el error si hay alguna forma de reproducirlo, pero no la hay. Este error ocurre de manera aleatoria, a veces ocurre un día después de la implementación, a veces ocurre 3-4 días después de la implementación. Pero sucede.

@antoinerousseau ¿Encontraste algo? ¿Alguien puede decirme paso a paso cómo depurar este problema al menos? He intentado todas las cosas por mi parte, pero 1-2 días después de implementar el sitio web se rompe. ¿Alguien puede decirme cómo saber cuándo sucederá este problema porque para mí sucede de manera demasiado aleatoria?

Lo que me solucionó es que tenía S3 configurado para devolver un 200 en la página 404. Cuando lo cambié para devolver un código de estado 404, funcionó.

¿S3 o Cloudfront?

En mi caso, el problema estaba en la página 404, utilizada por defecto por Azure. Fue un error de bloqueo y lo único que pude ver en la consola fue
Error / page resources for / not found. Not rendering React

Desde que comencé a usar 404 personalizado, el problema desapareció.

Me pasa lo mismo cuando implemento la aplicación en Netlify .. Localmente Gatsy Build y Gatsby Serve funcionan bien .. Esto es aún más extraño ..

@atapas , ¿puede comunicarse con el soporte de Netlify? ¿Puede ser que puedan aclarar algo de su lado?

@atapas , ¿puede comunicarse con el soporte de Netlify? ¿Puede ser que puedan aclarar algo de su lado?

Sí, lo hice. ¡Gracias!

Tal vez, aquí sería útil un mejor seguimiento de la pila o un mensaje de error claro. De todos modos, gracias por la respuesta.

@atapas No soy miembro de un equipo, solo sufro el mismo error que tú.

Me pasa lo mismo cuando implemento la aplicación en Netlify .. Localmente Gatsy Build y Gatsby Serve funcionan bien .. Esto es aún más extraño ..

Encontré la solución en un contexto completamente diferente. Recibía el error porque Netlify ignoraba las variables env que había configurado para que Auth0 funcionara en mi aplicación,

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

Más tarde leí acerca de "Implementar sin variables sensibles" desde aquí y lo arreglé como se menciona en el documento.

Estoy sorprendido con el error que obtuve y la solución aterrizó en ... pero me alegro de que haya funcionado.

@atapas No soy miembro de un equipo, solo sufro el mismo error que tú.

@ JustFly1984 , No se preocupe, realmente quería agradecerle. Miré el documento de Netlify y pude encontrar la solución como se menciona en el comentario anterior.

Recibo esto solo en Chrome. Safari funciona muy bien. Acabo de agregar los complementos sin conexión y de manifiesto a mi proyecto. No puedo reproducirlo con Gatsby develop o con gatsby build & gatsby serve localmente. Estoy alojando en Netlify.

Para mí, este bloque de código fuera de mi componente React, además de hacer referencia a las variables globales en el componente React, estaba causando el error. Eliminarlo solucionó el problema.

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