Gatsby: Recursos de erro / página para / não encontrado. Não renderizando React

Hiya!

Este problema ficou quieto. Silêncio assustador. 👻

Temos muitos problemas, então atualmente fechamos os problemas após 30 dias de inatividade. Já se passaram pelo menos 20 dias desde a última atualização aqui.
Se perdemos esse problema ou se você deseja mantê-lo em aberto, responda aqui. Você também pode adicionar o rótulo "não obsoleto" para manter este problema aberto!
Como um lembrete amigável: a melhor maneira de ver esse problema, ou qualquer outro, corrigido é abrir uma solicitação pull. Verifique gatsby.dev/contribute para obter mais informações sobre como abrir PRs, fazer a triagem de problemas e contribuir!

Obrigado por fazer parte da comunidade Gatsby! 💪💜

@antoinerousseau ajudaria se

Qual você acha que poderia ser a melhor maneira de seguir em frente? Você mesmo experimentou no safari / safari móvel?

@wardpeet obrigado por investigar isso.
Tentei com o desktop Safari e não consegui reproduzir. Eu não tenho um iPhone.
Não tenho certeza de como proceder, já que acontece apenas às vezes e aleatoriamente, mas um rastreamento de pilha melhor não pode prejudicar de qualquer maneira.
Note que isso só aconteceu 124 vezes, com 85% Mobile Safari, 10% Safari e 5% Chrome Mobile iOS. Várias versões.
Além disso, o URL nem sempre é / . Posso lhe dar acesso à conta do Bugsnag, se quiser.

Recebi o mesmo relatório de bug hoje. Apenas para que você saiba que não está sozinho.

Hiya!

Este problema ficou quieto. Silêncio assustador. 👻

Temos muitos problemas, então atualmente fechamos os problemas após 30 dias de inatividade. Já se passaram pelo menos 20 dias desde a última atualização aqui.
Se perdemos esse problema ou se você deseja mantê-lo em aberto, responda aqui. Você também pode adicionar o rótulo "não obsoleto" para manter este problema aberto!
Como um lembrete amigável: a melhor maneira de ver esse problema, ou qualquer outro, corrigido é abrir uma solicitação pull. Verifique gatsby.dev/contribute para obter mais informações sobre como abrir PRs, fazer a triagem de problemas e contribuir!

Obrigado por fazer parte da comunidade Gatsby! 💪💜

Olá de novo!

Já se passaram 30 dias desde que algo aconteceu sobre esse problema, então nosso amigável robô da vizinhança (sou eu!) Vai fechá-lo.
Lembre-se de que sou apenas um robô, portanto, se fechei este problema por engano, sou HUMAN_EMOTION_SORRY . Sinta-se à vontade para reabrir este problema ou criar um novo se precisar de mais alguma coisa.
Como um lembrete amigável: a melhor maneira de ver esse problema, ou qualquer outro, corrigido é abrir uma solicitação pull. Verifique gatsby.dev/contribute para obter mais informações sobre como abrir PRs, fazer a triagem de problemas e contribuir!

Obrigado novamente por fazer parte da comunidade Gatsby! 💪💜

Vendo a mesma coisa.

• É razoavelmente frequente (estamos vendo isso diariamente).
• Quase todos Mobile Safari ou Safari.
• Quase sempre / , mas muito raramente outras páginas.
• O Sentry fornece o mesmo rastreamento de pilha que o Bugsnag com as seguintes trilhas:
  

O mesmo aqui. Para uma página diferente de / index.

Dispositivo
Marca | Huawei
Família | DRA-LX5

SO
Nome Android
Versão | 8.1.0

Navegador
nome | Chrome Mobile WebView
versão | 70.0.3538

SDK
Nome sentry.javascript.browser
Versão | 5.12.1

Hiya!

Este problema ficou quieto. Silêncio assustador. 👻

Temos muitos problemas, então atualmente fechamos os problemas após 30 dias de inatividade. Já se passaram pelo menos 20 dias desde a última atualização aqui.
Se perdemos esse problema ou se você deseja mantê-lo em aberto, responda aqui. Você também pode adicionar o rótulo "não obsoleto" para manter este problema aberto!
Como um lembrete amigável: a melhor maneira de ver esse problema, ou qualquer outro, corrigido é abrir uma solicitação pull. Verifique gatsby.dev/contribute para obter mais informações sobre como abrir PRs, fazer a triagem de problemas e contribuir!

Obrigado por fazer parte da comunidade Gatsby! 💪💜

Ainda é um problema.

Eu também estou tendo esse problema. gatsby develop funciona bem, mas gatsby build faz com que o aplicativo seja interrompido com "Erro: recursos de página para / não encontrados. Não renderizando React." em tempo de execução, embora a própria construção seja bem-sucedida.

Isso pode ser causado pelo fato de eu estar usando o Typescript?

Tentei executar gatsby clean

Atualização / Solução possível : Para mim, o erro foi causado porque eu só tinha um arquivo ".env.development" e não um arquivo ".env.production". Não sei por que isso gerou um erro tão ambíguo / confuso e impediu o React de renderizar. Sinto que o comportamento esperado seria o mesmo que acontece quando executo gatsby develop . Quando executo gatsby develop e não tenho um arquivo .env.development, o React ainda é renderizado, mas meu aplicativo trava porque está faltando os valores importantes.

Eu tenho o mesmo problema. Meu aplicativo está hospedado no aws e usa o cloudfront. Tenho uma política de redirecionar todos os urls não existentes para a página 404.html com status 200 . Isso parece estranho, mas é realmente importante para um de nossos recursos. Portanto, no caso de eu digitar algo como my-test-site.com/some-not-existed-page window.pagePath seria /404.html que está correto, mas publicLoader.loadPage alguma forma não tenta carregar um 404.html conteúdo da página, mas /my-test-site.com/some-not-existed-page . Na verdade, ele usa window.location.pathname mas não window.pagePath

Recebi a mesma mensagem de erro no Sentry hoje: não encontrado. Não renderizando React

Eu também estava encontrando esse problema. Para mim, era reproduzível ao usar importações nomeadas para seus próprios componentes no arquivo pages/index.js .

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

components/index.js ficaria assim:

import Layout from "./Layout"

export {
  Layout
};

Isso foi com MacOS catelina & chrome Versão 80.0.3987.149.
"gatsby": "^2.20.13",

É importante observar que estou usando a variante expo gatsby.

Eu também tive esse problema ao executar um gatsby build limpo e a causa raiz foi uma resolução em meu package.json para uma vulnerabilidade de pacote acorn (consulte https://snyk.io/vuln/npm :bolota):

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

Remover esta resolução resolveu o problema para mim.

Resultado 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 

Ainda acontece muito (mais de 4.500 vezes na última semana):

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

/app-ac76ae7860adc4ef4414.js:1:179819

Migalhas de pão:

Tempo | Tipo | Erro | Infos
- | - | - | -
4ms antes | PEDIDO | Erro XMLHttpRequest | GET /page-data/app-data.json
5ms antes | PEDIDO | Erro XMLHttpRequest | GET /page-data/index/page-data.json
6ms antes | PEDIDO | Erro XMLHttpRequest | GET /page-data/app-data.json
7ms antes | PEDIDO | Erro XMLHttpRequest | GET /page-data/index/page-data.json
10ms antes | PEDIDO | Erro XMLHttpRequest | GET /page-data/app-data.json
10ms antes | PEDIDO | Erro XMLHttpRequest | GET /page-data/index/page-data.json

A maioria deles acontece no Mobile Safari e no Chrome Mobile:

Versão Gatsby: 2.20.13

Verifique esta solução.
https://github.com/gatsbyjs/gatsby/issues/11461#issuecomment -459732145

Eu não uso gatsby-plugin-offline então não há service workers.

Há algum progresso? Estou tendo um problema e tenho o plug-in off-line e não consigo desabilitá-lo para testar se há erros.

Não acho que isso tenha algo a ver com o plugin offline. Estamos vendo muitos desses erros e nunca os usamos.

Reproduzir:

• Vá para [o exemplo não é mais necessário, veja abaixo], observe o erro no console e o React não funcional.
• Navegue até a página inicial com o logotipo no canto superior esquerdo.
• Navegue de volta para a página original clicando em "Pesquisar" no cabeçalho. A página agora funciona e os painéis podem ser recolhidos.

Como faço para depurar isso? Não há solicitações de rede 404 ou algo assim, então não entendo o que está acontecendo. As versões locais são as seguintes, mas as compilações acontecem no 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

Em nosso caso, tínhamos uma página como exportação padrão e, em seguida, uma exportação nomeada também no arquivo de página. Assim que algo fazia referência à exportação nomeada de fora do arquivo de paginação, ficava muito confuso.

A correção era remover todas as exportações das páginas, exceto a exportação do componente da página real padrão.

@thekevinbrown O erro que você estava vendo era intermitente? Ou isso aconteceu todas as vezes?

@Undistraction toda vez que você iniciou ou atualizou a página com o problema. Se você começou em uma página diferente, ou navegou para fora da página para uma que estava funcionando, voltou, tudo bem. Então, basicamente, a hidratação inicial falha neste caso, enquanto se você conseguir colocar o usuário em uma página diferente onde a hidratação funciona, o download e a exibição da página quebrada funcionam.

Definitivamente teria sido melhor como um erro de compilação claro em vez de um erro de tempo de execução obscuro, se isso fosse possível.

@thekevinbrown, então acho que seu problema não está relacionado a este problema (que é um erro intermitente que ninguém conseguiu reproduzir de maneira confiável), então acho que embora você esteja vendo o mesmo erro, a causa é diferente (e felizmente você facilmente corrigido).

Esse erro foi encontrado em nosso site de produção e a atualização para a versão mais recente do Gatsby (lançada há apenas 2 dias) corrigiu o bug do Safari

Atualizado para a versão mais recente de Gatsby. O problema ainda ocorre

Eu nunca experimentei isso antes. De repente, isso acontece todas as vezes. Apenas na produção 😢
Isso aconteceu após uma atualização de 20 horas atrás. Atualizamos dependências com bastante regularidade.
Então, basicamente, o projeto está inativo e não tenho ideia de como fazê-lo funcionar novamente.

Tentei reverter as atualizações para o que eram há 20 horas. Não ajudou.
Reverter para 8 dias atrás também não ajudou.

Aqui está o projeto com atualizações mais recentes: https://vermehrungch-4utm3ymcd.now.sh/Vermehrung/
E aqui está o último funcionando de 8 dias atrás: https://vermehrungch-9l709pu84.now.sh/Vermehrung/

Revertendo as dependências do gatsby para o que eram há 9 dias, uma nova versão voltou a funcionar

Agora tentarei isolar o que a dependência de gatsby causa isso.

Ok, no nosso caso:

• definitivamente o próprio gatsby é a causa
• versões até 2.20.36 funcionam
• v2.21.2 e v2.21.3 têm erro acima (eu havia testado v2.21.17 antes, mesmo erro)
• v2.21.0 tem um erro 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)

Atualização: o erro ainda ocorre em gatsby v2.21.19

@barbalex você poderia compartilhar seu site conosco? Se for privado, envie um e-mail para [email protected].

Estou recebendo este erro no seu site quando o 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)

O site é:

• https://vermehrung.ch
• https://github.com/barbalex/vermehrung
• você pode até fazer login usando a senha enviada por e-mail

O site está em desenvolvimento. Então você pode até editar dados.

Recebemos as mesmas mensagens de erro no Sentry recorrentemente:

Estamos usando a versão "2.21.22" do gatsby.

Encontrei o mesmo problema e resolvi fazendo o downgrade para a v2.20.36, mencionada acima.

Ok, no nosso caso:

• definitivamente o próprio gatsby é a causa
• versões até 2.20.36 funcionam
• v2.21.2 e v2.21.3 têm erro acima (eu havia testado v2.21.17 antes, mesmo erro)

Corri para isso novamente em um projeto diferente que tinha a versão 2.21.12. Isso é _realmente_ ruim, pois ocorre apenas na produção. Priorize este bug.

Estamos vendo isso em produção em https://www.voteamerica.com/. Isso acontece principalmente no Mobile Safari, mas também estamos vendo no Android Chrome, desktop Safari, desktop Chrome e outros. No momento, estamos usando o Gatsby 2.21.40, mas também víamos o problema em 2.20.12

Tenho o mesmo problema para a página que foi excluída recentemente. https://intergiro.com/legal não mostra a página 404 personalizada como esperado (desktop Chrome, Gatsby 2.20.8). Também ocorre apenas na produção.

No meu caso, o comentário de @Kanuny indiretamente resolveu meu problema. Eu acidentalmente redirecionei o JSON de dados da página para um arquivo HTML quando publicLoader.loadPage estava tentando buscá-lo. Depois de corrigir os redirecionamentos, o JSON de dados da página carrega corretamente e tudo funciona normalmente.

O bug desapareceu de repente novamente. Parece que pode estar vinculado ao cache ou algo assim

O erro ainda está acontecendo na versão 2.22.12 no Firefox e nas versões mais recentes do Chrome também.

Corrija isso!

Corrija isso!

@SoldierCorp leia sobre o que é código aberto e talvez tente consertá-lo você mesmo.

@antoinerousseau é também uma ajuda mútua, onde quem precisa - pede e quem sabe - oferece. Então, acho que seu comentário está fora do lugar.

@andrzejwp sim, trata-se de ajudar uns aos outros, não de postar comentários mandões como "por favor, conserte!" sem nenhuma informação útil para realmente corrigir o problema, enquanto notifica 25 pessoas que seguem este problema.

Outros comentaram com percepções detalhadas sobre como isso os afeta, o que é necessário para fazer com que os contribuidores os ajudem e, com sorte, corrijam os problemas de OSS.

@antoinerousseau Não há mais informação útil relacionada a este porque não há mais informações fornecidas pelo problema então simplesmente acontece, então eu escrevi isso para evitar repetir as mesmas coisas que outras pessoas estão escrevendo porque é o mesmo no final até o última versão.

É apenas para informar a Gatsby que mais pessoas ainda estão enfrentando o problema e ainda não foi corrigido.

Desculpe se isso está incomodando você, mas eu sou um usuário regular que está usando o framework e por não ter tempo para corrigir o problema sozinho.

No meu caso, isso estava ocorrendo apenas ao prefixar caminhos, já que estou tentando usar gatsby-plugin-ipfs (Executar gatsby build --prefix-paths && gatsby serve resultaria em um "Erro / recursos de página para / não encontrados. Não renderizando React" para todos página).
No entanto, em minha página index.jsx, eu não estava executando nenhuma consulta de página, mas tinha um componente que continha uma staticQuery, do gancho useStaticQuery.
Se eu comentar este componente e o reconstruir, o erro irá embora.
Curiosamente, se eu descomentei este componente e reconstruísse novamente (para que o site voltasse ao estado inicial), ele funcionaria bem e não encontraria o erro "Erro / recursos de página para / não encontrado. Não renderizando React" sugerindo que o cache de construção contém algo importante?

Então, minhas idéias (aproximadas) sobre por que isso poderia ocorrer são:

• Problemas com a página de índice que contém uma consulta estática, mas não uma consulta de página?
• Problemas com a ordem do processo de construção (já que o cache pode modificar os resultados).
• Potencialmente, um problema com run static queries ou Generating image thumbnails no processo de compilação, uma vez que essas são as únicas etapas que parecem ser ignoradas graças ao cache.

Eu redirecionei acidentalmente o JSON de dados da página para um arquivo HTML

Situação semelhante aqui. Essencialmente, um regex de diretiva nginx location também correspondia a /page-data/items/page-data.json quando não deveria. Adicionar ^ no início da regexp evitou a correspondência não intencional.

Estamos vendo isso em produção em https://www.voteamerica.com/. Isso acontece principalmente no Mobile Safari, mas também estamos vendo no Android Chrome, desktop Safari, desktop Chrome e outros. No momento, estamos usando o Gatsby 2.21.40, mas também víamos o problema em 2.20.12

Também enfrentando o mesmo problema.

Olá equipe Gatsby, olá a todos. Seria possível especificar os erros retornados em loadPage que parece ser a origem dos vários erros apresentados nesta edição?

Consulte a função: https://github.com/gatsbyjs/gatsby/blob/030d927cddbdc64f8d93d409a5ada7442d5e62bf/packages/gatsby/cache-dir/loader.js#L179 -L242

É meu entendimento que esta função tenta carregar app-data.json , page-data.json e então os próprios componentes JS, sendo, portanto, muito propensa a problemas de rede, problemas de configuração de servidor, problemas de dev, problemas de configuração ... Ao especificar a mensagem de erro, seria mais fácil corrigir os problemas subjacentes.

(Para referência: a última ocorrência desse problema em nosso site foi devido a uma importação circular)

Tentei novamente com v2.23.12. Mesmo resultado: https://vermehrungch-1j64x2olp.vercel.app/Vermehrung

Para nós, parece absolutamente sistemático, uma vez que todas as versões acima de 2.20.36. Em cada um dos cinco aplicativos desenvolvidos com o gatsby. Portanto, fomos impedidos de atualizar desde então.

O que está começando a se tornar um problema. Por exemplo, estamos impedidos de usar qualquer libs usando core-js na v3 (https://github.com/gatsbyjs/gatsby/issues/15601). Esse problema agora foi resolvido - se _podemos_ atualizar.

Se houver alguma maneira em que eu possa ajudar com informações / testes / qualquer coisa, eu ficaria feliz.

@barbalex Você tem o seguinte erro em seu aplicativo:

Devemos definitivamente mostrar esse erro. Sinta-se à vontade para adicionar um PR, não tenho largura de banda suficiente para fazer este atm.

Parece que, em nosso caso, esse problema é causado pelo react-contextmenu quando essa lib é usada no lado do servidor: https://github.com/vkbansal/react-contextmenu/issues/284 , que parece ser acionado durante o processo de construção.

@wardpeet

Sinta-se à vontade para adicionar um PR, não tenho largura de banda suficiente para fazer isso atm

Lamento dizer, mas parece que não tenho células cinzentas suficientes para isso 😢
Talvez @ b4stien saiba ?

O problema ainda persiste na versão 2.23.21

Não tenho uma solução geral para isso, mas só queria que soubessem que tive esse problema pela primeira vez esta manhã.

E eu consegui "consertar" isso.

O site é hospedado na AWS por meio de um provedor chamado "Cloudways".

Como um teste inicial, implantei o site no Netlify - e tudo funcionou bem.

Depois de pesquisar um pouco, parecia haver um problema de cache do lado do servidor usando algo chamado "Varnish".

Primeiro tentei "purgá-lo" e nada aconteceu - mas desabilitar e habilitar funcionou.

Este site existe perfeitamente há cerca de 18 meses neste ambiente com atualizações regulares, e esta foi a primeira vez que encontrei esse problema.

Recentemente, atualizei para:
Gatsby CLI versão: 2.12.59

Não tenho certeza se isso poderia ter surtido algum efeito, mas é a única mudança em que consigo pensar - a menos, é claro, que tenha havido uma mudança no lado da hospedagem.

Espero que isso ajude alguém por aí 🤷

EDITAR:

O problema voltou em 5 minutos quando eu reativei o cache "verniz".

Desativei este recurso por enquanto.

Em nosso caso, todas as páginas criadas a partir da pasta /pages funcionam, mas o resto criado por createPages não reage à reidratação.
Estamos enfrentando esse problema tanto no local quanto no CI.

em nosso caso, todas as páginas criadas com createPages , porque estamos usando internacionalização com /${locale}/ prefixo para todas as páginas.

em nosso caso, todas as páginas criadas com createPages , porque estamos usando internacionalização com /${locale}/ prefixo para todas as páginas.

Você encontrou uma solução para isso? também temos essa configuração com muitos locais

@kdichev Não, não encontrei solução. Esperando a equipe de gatsby consertar isso no nível da biblioteca.

Ainda não tenho certeza de onde está o problema, eu ficaria feliz em fazer um PR sobre isso, mas gostaria que descobríssemos onde está o problema subjacente.

Ei pessoal, estou enfrentando este problema na produção usando o IE11.

"gatsby": "^ 2.23.11"

Também enfrentando um resultado em branco (sem hidratação) de todas as páginas do IE11.
Recursos da página para / não encontrados. Não renderizando reagir

Gatsby v2.24.2

EDIT: Eu reverti para a versão v2.22.11 de funcionamento anterior. ie11 funcionou naquele commit e com razão também funcionou agora, embora apenas quando eu mantive package-lock.json e npm ci. De alguma forma, não acredito que gatsby esteja errado, então estou listando algumas mudanças posteriores possíveis que podem ser relevantes:
(versão de trabalho -> versão de compilação com falha)
os grandes, que são prováveis ​​candidatos apenas para falhas ie11:
@ babel / core 7.10.0 -> 7.10.5
@ core / js 2.6.11 -> 3.6.5
gatsby-legacy-polyfills novo dep 0.0.2

outro menos provável:
@ graphql-tools / schema novo dep 6.0.14
@ graphql-tools / utils novo dep 6.0.14
e então minha paciência de peneirar tudo vermelho-> tudo verde na ferramenta vscode diff acabou

Outras coisas a serem observadas: eu reproduzi o erro com gatsby build && gatsby serve -H 0.0.0.0, de forma que isso exclui qualquer coisa do lado do ambiente do servidor.

EDIT 2: A saída de compilação da compilação fauly v2.24.2 relatada pela primeira vez em meu post foi de 10 MB para 30 MB. Tem cerca de 20 versões do app- {hash} .js, 2 do commons- {hash} .js e vários números de pages.js. Parece não ser exatamente os mesmos arquivos e eles são datados para corresponder às compilações anteriores. Portanto, parece que o gatsby build de alguma forma conseguiu todas as versões antigas disponíveis e as lançou em / public.

Alguém consegue compartilhar um repositório?

@roffelsaurus você pode tentar 2.23.22?
para nós, 2.24.2 está falhando em testes ci / cd cipreste.

Alguém consegue compartilhar um repositório?

podemos compartilhar nosso repo e vars em particular, se estiver tudo bem para você, envie um email para konstantin. [email protected] e vou convidá-lo para o nosso gh

@wardpeet, você pode testar este problema no repositório que lhe dei acesso relacionado ao problema # 25766

No meu caso, o problema estava relacionado à ordem de import e à forma como algumas bibliotecas (a saber react-leaflet ) são tratadas em um ambiente de renderização do lado do servidor. Tínhamos um plugin de folheto importado antes do próprio folheto causando o problema mais tarde. Consegui consertá-lo rapidamente quando soube onde procurar.

No entanto, acredito que a mensagem de erro que gerou ( page resources for / not found. Not rendering React ) foi incrivelmente confusa e a falta de detalhes e outros erros foi o principal problema, pois tive que cavar profundamente para saber o que isso significa.

Para qualquer outra pessoa com este problema: Como eu encontrei? O bom e velho ponto de interrupção e depuração no Chrome. gatsby build && gatsby serve permissão para ver o ambiente de produção localmente com todos os mapas de origem no lugar. Consegui depurar qual fragmento e, em seguida, o componente não está carregando e bagunce com as importações internas. Foi um processo bastante lento, então seja paciente, pois você estará recarregando a página indefinidamente. Procure o nome do seu trecho (no meu caso era component---src-pages-index-js ) e a importação atribuída a ele. Entre nele e observe suas dependências, pois um deles irá falhar. Acredito que em cada caso será diferente, por isso não se encontra uma boa solução em lugar nenhum. Os mapas de origem foram úteis, pois me mostraram mais do que apenas uma série de promessas genéricas no array.

Este não é o cerne do tópico, mas deixarei detalhes do que descobri abaixo. Porém, tenha em mente que abaixo é específico para o folheto de reação e sua milhagem irá variar:

Então, era assim que era originalmente:

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

e é assim que parece agora:

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

Claro, isso é um erro da nossa parte, já que qualquer plugin geralmente deve vir depois da biblioteca em que está sendo conectado. Como react-leaflet (eu acho) altera um pouco a ordem de carregamento ao executar a depuração, o problema não era visível durante o desenvolvimento.

Acabei de depurar Uncaught (in promise) Error: page resources for /app/ not found. Not rendering React no meu aplicativo. No meu caso, / app / é uma rota somente para cliente que contém um app react. Não tive problemas em gatsby develop , mas recebi este erro ao executar gatsby serve e também na construção de produção. Não houve erros de compilação relatados.

Acontece que o problema era com o react-contextmenu (https://github.com/vkbansal/react-contextmenu/issues/284) que o

@rgembalik , a forma como

Para mim, não consigo nem replicar, só vejo muitos desses erros no relatório de erros de sentinela. então não tenho certeza de como vou descobrir

Estamos recebendo muitos deles no Sentry com esses erros, bem como para todos os tipos de páginas além de apenas "/", também não foram capazes de replicar. Hospedado no Netlify. Eu suspeito que pode ter algo a ver com sessões ativas durante implantações, mas difícil de verificar.

@wardpeet parece que existem várias causas potenciais diferentes que desencadeiam esse mesmo erro. Para nós, vemos apenas esses erros em nosso registro de Sentinelas e nunca fomos capazes de reproduzi-los. Seria possível incluir mais informações com o erro ou adicionar vários erros mais granulares para que todos nós tivéssemos algo mais para continuar tentando descobrir a causa?

Acabei de receber este erro em https://www.gatsbyjs.com/ terminando com uma página em branco

Posso confirmar que no primeiro carregamento da página inicial, vi este erro em gatsbyjs.com

Eu descobri que Gatsby tem uma maneira particular de lidar com os caminhos de url com barras no final. Não sei se isso pode ajudar

Eu também estou tendo esse problema.

Não consigo compartilhar o repositório, mas se você acessar esta página, poderá ver que carrega um SVG corretamente. Mas, se eu for para uma rota que não existe, ex https://rocketseat.com.br/test exibe uma versão desatualizada do código (que ainda usa gatsby-image vez de um SVG) e mostra me esta mensagem no console:

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

Estou usando [email protected]

_edit: não sei porque, mas depois de adicionar meu problema aqui o problema da imagem foi resolvido, mas continuo recebendo o mesmo erro na página console_

É difícil para mim replicar, só vejo uma tonelada desses erros no relatório de erros de sentinela

@theskillwithin - mesmo. Milhares deles na Sentinela.

Estou tendo o mesmo problema. Muito estranho. Parece que existem várias causas que acionam esse erro.

Também estamos vendo esse erro acontecer em vários navegadores e em várias páginas. Não consigo relacionar nossa situação a nenhuma das possíveis causas mencionadas. E também não consigo replicar no desenvolvimento - isso só acontece com nosso site implantado.

Estou tendo o mesmo problema. não é capaz de replicar, mas muitos desses erros no sentinela. também variedade de navegadores
gatsby versão 2.24.3

Eles estão sendo relatados com frequência em um site de produção onde estou usando o Sentry também. Incapaz de me replicar. A meu ver, precisamos de relatórios melhores. O que é bizarro nisso é que ele, de fato, encontra os dados da página:

Como está recebendo o status 200 e AFAICT, o json não está malformado, presumo que fetchPageDataJson() está retornando uma resposta de sucesso:
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L137 -L151

Uma vez que tudo isso parece ser bem-sucedido, o próximo ponto de falha que vejo seria carregar o próprio componente:
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

Talvez haja um problema no async-requires que está sendo escrito. Eu imagino que eles estão realmente bem, no entanto, já que serão tratados pelo Webpack e o problema parece ser intermitente. Se houvesse um problema com a maneira como o arquivo é escrito, isso faria com que a compilação não funcionasse.

Se isso fosse algum tipo de problema de sintaxe em algum lugar do módulo que está sendo importado, imagino que falharia 100% das vezes. Talvez haja algo sendo usado em um módulo que não seja compatível com qualquer dispositivo / navegador que esteja carregando esse módulo. Difícil dizer, com certeza, já que o erro específico está sendo obscurecido.

O que acho que precisamos é do carregador de componente para _não_ comer o erro que é gerado.

Ter Promise.resolve() lá quando não existe um pedaço em asyncRequires significa que o erro lançado faria sentido. Esse erro também seria lançado em cada visita a essa página ... portanto, seria fácil rastrear a causa.

Retornar null no bloco catch significa que o erro lançado não faz sentido. O módulo foi encontrado, mas ocorreu um erro durante a importação dinâmica. O webpack não retorna um erro no bloco catch() de uma importação dinâmica? Do contrário, talvez esse seja um problema que deva ser abordado com o Webpack. Eu sei que se eu executar um import() incorreto de devtools, um erro é relatado ... se um erro é relatado ou não com base na incapacidade / falha em analisar o javascript sendo importado é outra questão alguns testes adicionais com algum código que _sei_ não funcionarão em certos navegadores.

@wardpeet, você mencionou um melhor relatório de erros anteriormente . Isso está em andamento ou é necessária ajuda?

Com relação à compatibilidade do navegador, vejo esses erros gerados principalmente por dispositivos móveis.

Mas também vi esses erros gerados no MacOS X usando Safari e no Windows 10 usando Chrome.

Um ponto comum é que o tráfego geralmente parece ser originário do Facebook ou Google. Mas isso pode ser apenas coincidência, já que são eles que direcionam a maior parte do nosso tráfego.

_NOTA: Este site com o qual estou trabalhando está, na verdade, usando [email protected] , então o código ao qual vinculei está em lugares diferentes, mas a lógica em si não parece ter mudado. Ainda está fazendo a mesma coisa, e os pontos potenciais de falha que identifiquei parecem ser os mesmos._

[email protected]

Também vejo o erro com pouca frequência no bugsnag. Não está claro se a página está sendo renderizada ou não para mim. Aqui está a pilha do bugsnag se for de alguma ajuda @wardpeet Interessante que neste caso ele parece ter tentado novamente várias vezes. Observe que esta é uma das muitas / webinar / blah ... páginas em que usamos createPage (), mas é claro, se eu tentar OBTER / page-data / ... como mostrado na foto, funcionará para mim.

Adicionarei algumas informações extras ao erro registrado para, com sorte, podermos encontrar o problema

Estou tendo o mesmo problema com uma página que originou outro bug postado em https://github.com/gatsbyjs/gatsby/issues/26706

No meu caso, isso acontece (pelo menos) no cromo da área de trabalho e só acontece na primeira vez que carrego a página, se eu clicar em atualizar, tudo será processado conforme o esperado

Então, se eu tento replicar aquela primeira vez, mesmo com o modo incognito e tentando apagar todos os caches que consigo pensar, não consigo (às vezes tenho conseguido, embora muito aleatoriamente), até depois de um tempo ( alguns dias) visito o url e encontro o mesmo erro (que desaparece após ser atualizado novamente)

Se eu tentar replicá-lo com o mesmo repositório mínimo que usei para o problema vinculado acima, não conseguirei ver os mesmos erros (pelo menos não nas vezes que tentei agora)

O erro é (neste caso) visível devido à grade de alvenaria não ter sido criada, o que no meu caso destrói a página a menos que o usuário pense em atualizá-la (suspeito que não)

Na verdade, parece tão aleatório que eu o vejo há algumas semanas, mas sempre pensei que era algo com o meu pc

Executei npm auidit fix e o problema foi corrigido para mim.

Segue! Têm o mesmo problema também

Olá,

Também estamos tendo esse problema apenas em produção. Reproduzimos esse bug 100% do tempo de urls específicos. Vamos ver a estrutura em árvore do nosso public dir:

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

Quando inserimos esses urls https://domain.com/usages/brainstorming ele funciona perfeitamente, https://domain.com/usages/seminaries também. Se inserirmos um url desconhecido como https://domain.com/doesnotexist teremos por direito a página 404, mas se tentarmos acessar um url que corresponda a uma pasta real na árvore, como https://domain.com/usages , teremos esta página em branco e este erro.

Isso pode soar um sino para você?

Melhor

@guillaumepotier , por acaso você usa o nginx também?

Acho que pode ser causado por cabeçalhos de resposta com defeito.

@ daydream05 sim, de fato, estamos usando o nginx. Vimos em nossos logs alguns cabeçalhos de conteúdo 304 Não modificado e, às vezes, 200 respostas.

usando o intervalo AWS S3

O mesmo aqui, hospedagem no AWS S3 (com CDN do CloudFront).

Executei npm audit fix e o problema foi corrigido para mim.

Interessante @ liuuuk311. Experimentei em nosso projeto e possivelmente também resolveu o problema para nós. O tempo dirá, mas até agora após 48h não há ocorrências em nossos logs.

Edit: 5 dias depois, ainda sem ocorrências ...

Edit: 10 dias depois e aconteceu algumas vezes novamente, desculpe informar. Executar npm audit fix por si só não parece resolver o problema.

@wardpeet alguns dados extras do bugsnag que podem ajudar a diagnosticar ...

De acordo com isso, parece que os arquivos page-data.json estão realmente carregando corretamente ...

• já que tropecei nisso hoje, vou esbarrar * e assistir aqui.

No meu caso, resolvi o problema ao carregar polyfill.io lib na página

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

@pedrofsantoscom explique como um script carregado estático resolve um problema para gatsby.js?

Tive o mesmo problema ontem. Limpar o cache localmente corrigiu para o usuário atual. Então, limpamos o cache no Cloudflare e agora não recebemos mais nenhum relatório.
Limpar o cache foi nossa solução

Não usamos Cloudflare, usamos AWS cloudfront CDN e ele é invalidado após cada implantação. Eu havia experimentado o bug localmente ao executar o servidor da web local com https com a primeira tentativa de execução após o servidor da web iniciar e também em algumas recargas de página consequentes, mas não sempre. Não vejo nenhum padrão. Isso só acontece de vez em quando.

Não usamos Cloudflare, usamos AWS cloudfront CDN e ele é invalidado após cada implantação. Eu havia experimentado o bug localmente ao executar o servidor da web local com https com a primeira tentativa de execução após o servidor da web iniciar e também em algumas recargas de página consequentes, mas não sempre. Não vejo nenhum padrão. Isso só acontece de vez em quando.

Essa foi a solução para nós. Quando limpamos o cache, os erros por hora diminuíram rapidamente e não obtivemos o mesmo erro pelo menos no bugsnag. Este é realmente um erro estranho.

Recebi a mesma mensagem de erro, mas apenas no Internet Explorer. Todos os outros navegadores não mostraram esse tipo de mensagem de erro.

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

Rastreei o problema até uma importação que fiz em meus componentes de reação. Em alguns casos, eu tinha dependências para https://sap.github.io/ui5-webcomponents/ . Depois de remover essas dependências, o problema foi embora. Não posso explicar qual é a verdadeira causa raiz, mas gostaria de salientar que dependências em seus controles de reação podem causar esse problema.

@Chaosbohne não pode argumentar contra isso, mas eu diria que é uma questão de gatsby.js cuidará do gerenciamento de dependências e da segurança e, na primeira etapa, removerá ^ de todas as versões de dependências / devDependências, uma série de problemas podem ser evitados.

Posso dizer que esse problema não depende do navegador. Eu vi isso no Chrome e Safari com base em logs do Sentry, e no Chrome 85, 86 localmente no meu mac.

Nenhuma das soluções funciona. @KyleAMathews por causa deste problema estamos perdendo negócios, dentro de 3-4 dias esse problema acontece e não somos capazes de descobrir a causa raiz dele. Ajude-nos a encontrar a solução para esse problema.

@ R3coN você tentou reconstruir seu site? Quando isso aconteceu conosco, basicamente tentamos de novo (isso foi há um tempo, não me lembro por que foi corrigido)

@ R3coN se puder ajudar, aqui estão as versões de pacote que usamos e que estão funcionando bem:

    "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 sim, essa é a única maneira de consertar, reconstruindo o site novamente. Mas a reconstrução também corrige o problema por 2 a 3 dias e, então, novamente esse problema surge. Estamos usando a versão CLI do Gatsby: 2.12.67 e a versão do Gatsby: 2.24.47, pois você mencionou que a versão 2.20.36 do gatsby está funcionando bem para você, tentaremos a sorte rebaixando a versão do gatsby.

@ shide1989 Obrigado pelo comentário. Mas fazer o downgrade da versão me lança este erro ->

WebpackError: O resultado desta StaticQuery não pôde ser obtido.

Que estava funcionando na versão anterior 2.24.47.

Lamento ouvir isso, talvez você não tenha um literal de modelo com tag Graphql no mesmo arquivo em que o gancho useStaticQuery é usado para extrair consultas em tempo de construção. (conforme descrito aqui: https://github.com/gatsbyjs/gatsby/issues/24526)

de qualquer maneira, boa sorte com isso

Mas eu disse a você que o mesmo código estava funcionando para gatsby 2.24.47.

@ R3coN este problema também pode ser causado por cache estático impróprio. Se você estiver usando nginx ou s3 para o seu servidor e não invalidar seu page-data.json, seu StaticQueries será interrompido sempre que você alterar seus dados.

Eu tive esse problema e descobri que estava armazenando em cache todo o page-data.json. Eles não deveriam ser. Eles devem ser revalidados a cada solicitação

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

@ daydream05 Obrigado pelo comentário. Sim, estou usando o S3 com o CloudFront. Você tem alguma ideia de como conseguir isso com o Cloudfront?

@ daydream05 Já tenho o cache-control: 'public, max-age = 0, must-revalidate' adicionado a page-data.json e app-data.json, o que significa que essas páginas não são armazenadas em cache.

Estou vendo isso também em páginas que não existem (o que deve carregar e hidratar a página 404).

Localmente, minhas compilações de desenvolvimento e produção funcionam sem esse erro, e quando insiro um console.log durante a verificação que lança esse erro na produção construída app-[hash].js , posso ver que page object existe e inclui page.componentChunkName: ""component---src-pages-404-js" como eu esperava que deveria.

No entanto, quando o aplicativo é implantado na nuvem gatsby, o erro ocorre a cada carregamento de uma página inexistente. A página 404 do SSR é exibida no navegador, mas, em seguida, o erro é gerado, portanto, o React nunca é executado no navegador. Quando a página 404 é carregada diretamente (visitando o caminho /404 ), ela funciona bem, sem erros.

Isso é difícil de diagnosticar porque não fui capaz de replicar localmente até agora.

Usando a versão mais recente: "gatsby": "^2.24.91"

Apenas postando isso aqui para permitir que outras pessoas usem react-md para consertar rapidamente seu site ou esperando que isso possa ajudar de alguma forma a corrigir esse problema em Gatsby.

Eu tive o mesmo erro em um dos meus projetos, onde estava usando react-md
Depois de remover todos os componentes, consegui me livrar do problema.

Já que tive que implantar para estimular todas as vezes para testar isso, não consegui identificar qual componente específico tem esse problema, mas reduzi-o 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";

Estarei atualizando minha postagem do blog sobre esse problema se tiver tempo para me aprofundar.

Em relação a 404 páginas, posso confirmar o problema de @aMoniker , pois o mesmo padrão de comportamento está acontecendo comigo.

Localmente, as compilações de desenvolvimento e produção funcionam bem com a página 404 , mas quando implantado na nuvem Gatsby, recebo o problema em todas as páginas desconhecidas, exceto no caminho /404 real.

Eu também encontrei esse erro e o corrigi limpando o cache do navegador. No entanto, seria bom encontrar uma solução que não exija isso, pois não podemos forçar todos os nossos usos a fazer isso.

@ dejavu1987 não estamos usando o

@MaciekBaron Eu reproduzi um erro localmente limpando o cache do navegador várias vezes e recarregando a página após cada limpeza.

Este parece ser um problema de cache, como mencionei anteriormente. Se seus cabeçalhos de cache estiverem configurados corretamente, o problema pode ser com service workers.

Talvez dê uma chance a este plugin?
https://www.npmjs.com/package/gatsby-plugin-remove-serviceworker

Ei, também corro para esse problema. No desenvolvimento, tudo está funcionando bem, mas quando executo o gatsby build e implanto o diretório público no meu web hoster, uma página falha devido a essa mensagem de erro.

Fiquei muito curioso e olhei para o diretório de dados da página pública. Descobri que o diretório específico da página existe, mas não estava em letras minúsculas, em vez disso, o diretório estava em letras maiúsculas. Esse foi o problema que recebi a mensagem de erro.

Depois disso, mudei para uma letra minúscula no início e está funcionando bem no prod. Acho que isso ocorre porque mudei o nome da página anteriormente e talvez algo esteja armazenado em cache aqui?

Eu também me deparo com esse problema. Eu encontrei um método para corrigir esse problema. Mas acho que não resolveu o verdadeiro problema.

Agora, deixe-me explicar como consertar.

Esse problema foi encontrado no ambiente de teste ou produção, como todos dizem acima, ele não se reproduz no desenvolvimento. Mesmo em teste ou produção, isso não ocorria sempre. E descobri que todos os scripts foram pré-carregados e executados de forma assíncrona. Então eu acho que pode ser causado pela ordem executiva dos scripts.

À medida que desacelero a rede na rede, como definido como 3G fast , o problema quase sempre ocorria. Isso confirmou meu palpite.

Para validar meu palpite, mudei o processo de renderização de HTML em gatsby-ssr.js para definir todos os scripts sem "async" , como segue:

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

Felizmente, funciona.

Embora essa maneira possa ajudar a corrigir o problema, não acho que seja uma boa maneira de fazer isso. Parece violar a característica do gatsby. O script de execução assíncrona é projetado para ser assim?

Esperançosamente, esta forma pode resolver todos os seus problemas também.

Esse problema foi encontrado no ambiente de teste ou produção, como todos dizem acima, ele não se reproduz no desenvolvimento. Mesmo em teste ou produção, isso não ocorria sempre. E descobri que todos os scripts foram pré-carregados e executados de forma assíncrona. Então eu acho que pode ser causado pela ordem executiva dos scripts.

Embora essa maneira possa ajudar a corrigir o problema, não acho que seja uma boa maneira de fazer isso. Parece violar a característica do gatsby. O script de execução assíncrona é projetado para ser assim?

Acho que você está certo, tive esse problema de voltar por motivos estranhos.
A última foi maluca, mas quando a conecto à sua resposta, faz sentido.

Portanto, recentemente adicionei um componente de ícone de fonte ao meu componente de layout e ele reproduziu esse problema.
Um ponto importante a ser observado é que os ícones de fonte foram usados ​​em outros componentes aninhados profundamente todo esse tempo e nunca causou o problema, apenas quando está no nível de layout, que é o primeiro componente chamado de qualquer componente da página.

Posso estar errado, mas este pode ser um bom cenário para descobrir a causa real.

@ dejavu1987 Concordo com você. Talvez você tenha fornecido um bom cenário para descobrir a causa real.

Além disso, eu me pergunto se é adequado carregar e executar os scripts com async , pois o webpack divide os códigos em partes diferentes, mas as partes podem ter dependências.

O principal problema parece ser que Gatsby engole erros durante o carregamento da página e apenas relata a mensagem page resources for / not found. Not rendering React muito genérica, que é o motivo pelo qual existem tantas causas potenciais diferentes relatadas neste tópico.

Meu problema acabou sendo que o Mobx 5 não oferece suporte ao IE11 e, embora o Mobx forneça uma boa mensagem de erro para isso, tudo o que recebi foi a mensagem "recursos da página não encontrados" de Gatsby, que era um tanto enganosa.

Eu humildemente sugeriria como solução para esse problema relatar a mensagem de erro original que causou a falha no carregamento da página. @wardpeet

O que consertou para mim é que eu tinha S3 configurado para retornar 200 na página 404. Quando mudei para retornar um código de status 404, funcionou.

Sim, também encontrei isso. No entanto, meu problema era mais amplo ... Eu estava armazenando em cache de forma inadequada nos resultados do Cloudfront 404. O motivo pelo qual obtive resultados 404 entre o Cloudfront e o S3 é que a implantação no S3 via CodePipeline, acredito, descompacta o arquivo ZIP do Build Artifact - mas não o faz em uma ordem específica. Portanto, por alguns minutos, você pode ter novos arquivos .HTML apontando para novos arquivos .JS (com novos hashes) que ainda não existem. Qualquer coisa que lida com o cache de seus arquivos de ativos com hash não deve armazenar em cache em resultados 404, pois isso só pode ser corrigido esvaziando o cache CDN.

Alguém descobriu como garantir que os arquivos HTML sejam implantados no S3 por último?

David
https://ewebinar.com

Em 21 de outubro de 2020, às 12h40, Vince P. [email protected] escreveu:

@ R3coN https://github.com/R3coN este problema também pode ser causado por cache estático impróprio. Se você estiver usando nginx ou s3 para o seu servidor e não invalidar seu page-data.json, seu StaticQueries será interrompido sempre que você alterar seus dados.

Eu tive esse problema e descobri que estava armazenando em cache todo o page-data.json. Eles não deveriam ser. Eles devem ser revalidados a cada solicitação

https://www.gatsbyjs.com/docs/caching/ https://www.gatsbyjs.com/docs/caching/
-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/gatsbyjs/gatsby/issues/19618#issuecomment-713298516 ou cancele a inscrição https://github.com/notifications/unsubscribe-auth/AA3SHT55MXZTXQUAXH5ZJPY3SLZQ4VANCNIKQ4 .

Posso acrescentar que reproduzi um problema com o Chrome Lighthouse Audit em testes móveis, com e sem testes PWA. Tenho certeza de que os testes móveis usam limites de rede e de CPU, então scripts assíncronos carregando fora de ordem ou um de 30 falhando ... pode ser uma situação muito frequente.

Estou trabalhando com 3D e mesmo em localhost com webpack e gatsby.js , recarregar a página quase sempre resulta em solicitações de rede com falha para o modelo estático gtlf arquivos. Um deles falhou - todo o aplicativo está quebrado (se nenhum ErrorBoundary definido).

Acho que aqui pode haver o mesmo padrão, mas sem o tratamento de erros adequado.

Estou usando o S3 e o CloudFront para produção. Eu tive um problema semelhante, mas no meu caso estava recebendo Can't render React erro no console apenas no Cloudfront. Isso começou a acontecer após a alteração de arquivos no S3 de produção. Para minha surpresa, o problema foi resolvido após a reexecução do farol para origem da produção.

Isso só estava acontecendo no meu dispositivo no modo normal. No meu caso, limpar o cache inteiro, cookies, armazenamento local, armazenamento de sessão e service workers não ajudou antes.

Portanto, se você traçar o perfil de sua origem de produção com farol e os arquivos forem alterados, esse problema também pode ocorrer (no meu caso, foi)

Meu ponto é que posso reproduzi-lo com lighthouse praticamente 1 de 10, e a última implantação foi há muito tempo.

Não acho que gatsby seja capaz de resolver esse problema, porque isso está acontecendo com todos, mas o motivo é diferente. Eu recebo páginas em branco com muita frequência ou sempre que mudo algo no backend, a página do gatsby fica em branco e gera um erro, e esse erro também é diferente a cada vez. Acho que temos que parar de usar o gatsby e mudar para alguma outra estrutura confiável.

Eu poderia consertar o erro se houvesse alguma maneira de reproduzi-lo, mas não há. Este erro acontece aleatoriamente, às vezes acontece um dia depois da implantação, às vezes acontece 3-4 dias após a implantação. Mas acontece.

@antoinerousseau Você achou alguma coisa? Alguém pode me dizer passo a passo como, pelo menos, depurar esse problema? Eu tentei todas as coisas do meu lado, mas 1-2 dias depois de implantar as quebras de site. Alguém pode me dizer como saber quando esse problema vai acontecer porque para mim acontece de forma muito aleatória?

O que consertou para mim é que eu tinha S3 configurado para retornar 200 na página 404. Quando mudei para retornar um código de status 404, funcionou.

S3 ou Cloudfront?

No meu caso, o problema estava na página 404, usada por padrão pelo Azure. Foi um erro de bloqueio e a única coisa que consegui ver no console foi
Error / page resources for / not found. Not rendering React

Desde que comecei a usar o custom 404 - o problema desapareceu.

Eu recebo o mesmo quando implanto o aplicativo no Netlify .. Locally Gatsy Build e Gatsby Serve funcionam bem .. Isso é ainda mais estranho ..

@atapas, você pode entrar em contato com o suporte do Netlify? podem ser eles podem esclarecer algo de seu lado?

@atapas, você pode entrar em contato com o suporte do Netlify? podem ser eles podem esclarecer algo de seu lado?

Sim eu fiz. Obrigado!

Talvez, um rastreamento de pilha melhor ou uma mensagem de erro clara sejam úteis aqui. De qualquer forma, obrigado pela resposta.

@atapas Não sou membro de uma equipe, apenas sofro do mesmo bug que você.

Eu recebo o mesmo quando implanto o aplicativo no Netlify .. Locally Gatsy Build e Gatsby Serve funcionam bem .. Isso é ainda mais estranho ..

Eu encontrei a solução em um contexto completamente diferente. Eu estava recebendo o erro porque o Netlify estava ignorando as variáveis ​​env que eu tinha definido para Auth0 para funcionar em meu aplicativo,

domínio: process.env.AUTH0_DOMAIN,
clientID: process.env.AUTH0_CLIENTID,
redirectUri: process.env.AUTH0_CALLBACK,

Posteriormente, li sobre o "Implantar sem variáveis ​​confidenciais" a partir daqui e corrigi-lo conforme mencionado no documento.

Estou surpreso com o erro que recebi e a solução caiu ... mas estou feliz que funcionou.

@atapas Não sou membro de uma equipe, apenas sofro do mesmo bug que você.

@ JustFly1984 , Não se preocupe, eu realmente queria agradecer. Eu olhei para o documento do Netlify e pude descobrir a solução conforme mencionado no comentário acima.

Estou recebendo isso apenas no Chrome. Safari funciona muito bem. Acabei de adicionar os plug-ins offline e de manifesto ao meu projeto. Não consigo reproduzi-lo com Gatsby develop ou com gatsby build & gatsby serve localmente. Estou hospedando no Netlify.

Para mim, esse bloco de código fora do meu componente React, bem como a referência às variáveis ​​globais no componente React, estava causando o erro. Removê-lo corrigiu o 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)
  );
}