Gatsby: Ошибка / ресурсы страницы для / не найдены. Не отображается React

Привет!

Этот вопрос утих. Жуткая тишина. 👻

У нас много проблем, поэтому в настоящее время мы закрываем их после 30 дней бездействия. Прошло не менее 20 дней с момента последнего обновления здесь.
Если мы пропустили эту проблему или вы хотите оставить ее открытой, ответьте здесь. Вы также можете добавить ярлык «не устаревший», чтобы эта проблема оставалась открытой!
В качестве дружеского напоминания: лучший способ увидеть эту или любую другую исправленную проблему - это открыть запрос на слияние. Посетите gatsby.dev/contribute для получения дополнительной информации об открытии PR, проблемах с

Спасибо, что стали частью сообщества Гэтсби! 💪💜

@antoinerousseau. Поможет ли нам улучшить трассировку стека? Возможно, это было 404 или, может быть, данные страницы неверны. На данный момент вы действительно не видите разницы.

Как вы думаете, каким может быть лучший способ двигаться вперед? Вы сами пробовали это на мобильном сафари / сафари?

@wardpeet спасибо, что
Я попытался использовать рабочий стол Safari, но не смог воспроизвести. У меня нет iPhone.
Я не уверен, что делать дальше, так как это случается только иногда и случайным образом, но лучшая трассировка стека в любом случае не повредит.
Обратите внимание, что это произошло всего 124 раза: 85% Mobile Safari, 10% Safari и 5% Chrome Mobile iOS. Различные версии.
Также URL-адрес не всегда / . Я могу предоставить вам доступ к учетной записи Bugsnag, если хотите.

Сегодня у меня был такой же отчет об ошибке. Просто чтобы вы знали, что вы не одиноки.

Привет!

Этот вопрос утих. Жуткая тишина. 👻

У нас много проблем, поэтому в настоящее время мы закрываем их после 30 дней бездействия. Прошло не менее 20 дней с момента последнего обновления здесь.
Если мы пропустили эту проблему или вы хотите оставить ее открытой, ответьте здесь. Вы также можете добавить ярлык «не устаревший», чтобы эта проблема оставалась открытой!
В качестве дружеского напоминания: лучший способ увидеть эту или любую другую исправленную проблему - это открыть запрос на слияние. Посетите gatsby.dev/contribute для получения дополнительной информации об открытии PR, проблемах с

Спасибо, что стали частью сообщества Гэтсби! 💪💜

Привет снова!

Прошло 30 дней с тех пор, как что-то случилось по этой проблеме, поэтому наш дружелюбный соседский робот (это я!) Собирается закрыть ее.
Имейте в виду, что я всего лишь робот, поэтому, если я закрыл эту проблему по ошибке, я буду HUMAN_EMOTION_SORRY . Пожалуйста, не стесняйтесь повторно открыть эту проблему или создать новую, если вам что-то еще нужно.
В качестве дружеского напоминания: лучший способ увидеть эту или любую другую исправленную проблему - это открыть запрос на слияние. Посетите gatsby.dev/contribute для получения дополнительной информации об открытии PR, проблемах с

Еще раз спасибо за то, что вы являетесь частью сообщества Гэтсби! 💪💜

Видя то же самое.

• Это довольно часто (мы наблюдаем это ежедневно).
• Почти все Mobile Safari или Safari.
• Почти всегда / , но очень редко другие страницы.
• Sentry дает такую ​​же трассировку стека, что и Bugsnag, со следующими хлебными крошками:
  

Тоже самое. Для страницы, отличной от / index.

Устройство
Бренд | Huawei
Семья | DRA-LX5

Операционные системы
Имя | Android
Версия | 8.1.0

Браузер
имя | Chrome Mobile WebView
версия | 70.0.3538

SDK
Имя | sentry.javascript.browser
Версия | 5.12.1

Привет!

Этот вопрос утих. Жуткая тишина. 👻

У нас много проблем, поэтому в настоящее время мы закрываем их после 30 дней бездействия. Прошло не менее 20 дней с момента последнего обновления здесь.
Если мы пропустили эту проблему или вы хотите оставить ее открытой, ответьте здесь. Вы также можете добавить ярлык «не устаревший», чтобы эта проблема оставалась открытой!
В качестве дружеского напоминания: лучший способ увидеть эту или любую другую исправленную проблему - это открыть запрос на слияние. Посетите gatsby.dev/contribute для получения дополнительной информации об открытии PR, проблемах с

Спасибо, что стали частью сообщества Гэтсби! 💪💜

По-прежнему проблема.

Я тоже получаю эту проблему. gatsby develop работает нормально, но gatsby build вызывает сбой приложения с сообщением «Ошибка: ресурсы страницы для / не найдены. Не отображается React». во время выполнения, даже если сама сборка завершается успешно.

Может ли это быть вызвано тем, что я использую Typescript?

Я пробовал запустить gatsby clean

Обновление / возможное решение : для меня ошибка была вызвана тем, что у меня был только файл «.env.development», а не файл «.env.production». Я не знаю, почему это дало такую ​​неоднозначную / запутанную ошибку и помешало React отрисовке. Я чувствую, что ожидаемое поведение будет таким же, как и при запуске gatsby develop . Когда я запускаю gatsby develop и у меня нет файла .env.development, React по-прежнему отображает, но мое приложение вылетает из-за отсутствия важных значений.

У меня такая же проблема. Мое приложение размещено на AWS и использует Cloudfront. У меня есть политика перенаправления всех несуществующих URL-адресов на страницу 404.html со статусом 200 . Это выглядит странно, но это действительно важно для одной из наших функций. Итак, если я наберу что-то вроде my-test-site.com/some-not-existed-page window.pagePath будет /404.html что правильно, но publicLoader.loadPage почему-то пытается загрузить не 404.html содержимое страницы, но /my-test-site.com/some-not-existed-page . На самом деле он использует window.location.pathname но не window.pagePath

Сегодня у меня такое же сообщение об ошибке в Sentry: не найдено. Не отображается React

Я тоже столкнулся с этой проблемой. Для меня это было воспроизводимо при использовании именованного импорта для ваших собственных компонентов в файле pages/index.js .

пример
import Layout from "../components/Layout"; ✅
import { Layout } from "../components"; 🚫

components/index.js будет выглядеть так:

import Layout from "./Layout"

export {
  Layout
};

Это было с MacOS catelina & chrome версии 80.0.3987.149.
"gatsby": "^2.20.13",

Важно отметить, что я использую вариант expo gatsby.

У меня также была эта проблема при запуске чистого gatsby build и основной причиной было разрешение в моем package.json уязвимости пакета acorn (см. Https://snyk.io/vuln/npm :желудь):

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

Удаление этого разрешения решило проблему для меня.

Вывод из 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 

По-прежнему происходит много (более 4500 раз за последнюю неделю):

Stacktrace в мобильном 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 для Chrome Mobile:

/app-ac76ae7860adc4ef4414.js:1:179819

Панировочные сухари:

Время | Тип | Ошибка | Информация
- | - | - | -
За 4 мс до | ЗАПРОС | Ошибка XMLHttpRequest | ПОЛУЧИТЬ /page-data/app-data.json
За 5 мс до | ЗАПРОС | Ошибка XMLHttpRequest | ПОЛУЧИТЬ /page-data/index/page-data.json
За 6 мс до | ЗАПРОС | Ошибка XMLHttpRequest | ПОЛУЧИТЬ /page-data/app-data.json
За 7 мс до | ЗАПРОС | Ошибка XMLHttpRequest | ПОЛУЧИТЬ /page-data/index/page-data.json
За 10 мс до | ЗАПРОС | Ошибка XMLHttpRequest | ПОЛУЧИТЬ /page-data/app-data.json
За 10 мс до | ЗАПРОС | Ошибка XMLHttpRequest | ПОЛУЧИТЬ /page-data/index/page-data.json

Большинство из них происходит в Mobile Safari и Chrome Mobile:

Версия Гэтсби: 2.20.13

Проверьте это решение.
https://github.com/gatsbyjs/gatsby/issues/11461#issuecomment -459732145

Я не использую gatsby-plugin-offline поэтому нет сервис-воркеров.

Есть ли прогресс? У меня проблема, и у меня плагин не в сети, и я не могу отключить плагин, чтобы проверить, не исчезли ли ошибки.

Я не думаю, что это имеет какое-то отношение к офлайн-плагину. Мы видим множество таких ошибок и никогда не использовали их.

Воспроизвести:

• Перейдите к [пример больше не нужен, см. Ниже], обратите внимание на ошибку в консоли и неработающий React.
• Перейдите на главную страницу с логотипом вверху слева.
• Вернитесь на исходную страницу, нажав «Исследование» в заголовке. Страница теперь работает, панели складные.

Как мне отладить это? Нет сетевых запросов, которые 404 или что-то еще, поэтому я не понимаю, что происходит. Локальные версии следующие, но сборки происходят на 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

В нашем случае у нас была страница в качестве экспорта по умолчанию, а затем также был именованный экспорт в файле страницы. Как только что-либо ссылалось на названный экспорт извне файла подкачки, это очень сбивало с толку.

Исправление заключалось в удалении всех экспортов со страниц, кроме фактического экспорта компонентов страницы по умолчанию.

@thekevinbrown Была ли ошибка, которую вы наблюдали периодически? Или это происходило каждый раз?

@Undistraction каждый раз, когда вы запускали или обновляли страницу с проблемой. Если вы начали на другой странице или перешли со страницы на рабочую, а затем вернулись, все было в порядке. Таким образом, в этом случае начальная гидратация в основном не выполняется, тогда как если вы можете перенаправить пользователя на другую страницу, где работает гидратация, то загрузка и отображение поврежденной страницы будут работать.

Определенно было бы лучше в качестве явной ошибки сборки вместо скрытой ошибки времени выполнения, если это возможно.

@thekevinbrown, поэтому я думаю, что ваша проблема не связана с этой проблемой (это периодическая ошибка, которую никто не смог надежно воспроизвести), поэтому я думаю, что, хотя вы видите ту же ошибку, причина в другом (и, к счастью, вы легко починил).

Обнаружена эта ошибка на нашем сайте prod, и обновление до последней версии Gatsby (выпущенной всего 2 дня назад) исправило ошибку для Safari.

Обновился до последней версии Gatsby. Проблема все еще возникает

Я никогда раньше такого не испытывал. Вдруг это происходит каждый раз. Только в производстве 😢
Произошло это после обновления 20 часов назад. Мы довольно регулярно обновляем зависимости.
В общем, проект не работает, и я не знаю, как заставить его снова работать.

Я попытался вернуть обновления к тому, что было 20 часов назад. Не помогло.
Возврат к 8-дневной давности тоже не помог.

Вот проект с новыми обновлениями: https://vermehrungch-4utm3ymcd.now.sh/Vermehrung/
И вот последний рабочий, сделанный 8 дней назад: https://vermehrungch-9l709pu84.now.sh/Vermehrung/

Вернув зависимости Гэтсби к тому, что было 9 дней назад, новая сборка снова заработала 😆

Теперь попытаемся выделить причину зависимости Gatsby.

Хорошо, в нашем случае:

• определенно сам Гэтсби является причиной
• версии до 2.20.36 работают
• v2.21.2 и v2.21.3 имеют указанную выше ошибку (я тестировал v2.21.17 ранее, такая же ошибка)
• v2.21.0 имеет другую ошибку:
  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)

Обновление: ошибка по-прежнему возникает в gatsby v2.21.19

@barbalex не могли бы вы поделиться с нами своим сайтом? Если это личное, отправьте электронное письмо на адрес [email protected].

Я получаю эту ошибку на вашем сайте при отладке

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

Трассировки стека:

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)

Сайт:

• https://vermehrung.ch
• https://github.com/barbalex/vermehrung
• вы даже можете войти в систему, используя пароль, отправленный по почте

Сайт в разработке. Так что вы даже можете редактировать данные.

Мы периодически получаем одни и те же сообщения об ошибках в Sentry:

Мы используем версию gatsby "2.21.22".

Я столкнулся с той же проблемой и был исправлен переходом на версию 2.20.36, о которой говорилось выше.

Хорошо, в нашем случае:

• определенно сам Гэтсби является причиной
• версии до 2.20.36 работают
• v2.21.2 и v2.21.3 имеют указанную выше ошибку (я тестировал v2.21.17 ранее, такая же ошибка)

Я снова столкнулся с этим в другом проекте с версией 2.21.12. Это действительно плохо, так как встречается только на производстве. Пожалуйста, сделайте эту ошибку приоритетной.

Мы видим это в производстве на https://www.voteamerica.com/. Это происходит в основном в Mobile Safari, но мы также наблюдаем это в Android Chrome, настольном Safari, настольном Chrome и других. В настоящее время мы используем Gatsby 2.21.40, но проблема возникла и в 2.20.12.

Та же проблема для одной страницы, которая была недавно удалена. https://intergiro.com/legal не отображает настраиваемую страницу 404, как ожидалось (настольный Chrome, Gatsby 2.20.8). Также встречается только в производстве.

В моем случае комментарий @Kanuny косвенно решил мою проблему. Я случайно перенаправил данные страницы JSON в файл HTML, когда publicLoader.loadPage пытался его получить. После исправления переадресации данные страницы JSON загружаются правильно, и все работает в обычном режиме.

Баг внезапно снова исчез. Похоже, это может быть связано с кешем или чем-то еще

Ошибка по-прежнему возникает в версии 2.22.12 в последних версиях Firefox и Chrome.

Пожалуйста, исправьте!

Пожалуйста, исправьте!

@SoldierCorp, пожалуйста, прочтите о том, что такое Open Source, и, возможно, попробуйте исправить это самостоятельно.

@antoinerousseau - это еще и помощь друг другу, когда те, кто в ней нуждается, просят об этом, а те, кто умеет, предлагают ее. Думаю, ваш комментарий неуместен.

@andrzejwp да, это о том, чтобы помогать друг другу, а не о том, чтобы оставлять властные комментарии вроде «пожалуйста, исправьте!» без какой-либо полезной информации, чтобы на самом деле решить проблему, уведомив 25 человек, отслеживающих эту проблему.

Другие прокомментировали подробные сведения о том, как это влияет на них, что необходимо для того, чтобы участники помогли им и, надеюсь, исправят проблемы с OSS.

@antoinerousseau Больше нет никакой полезной информации, связанной с этим, потому что больше нет информации, предоставленной проблемой, так что это просто происходит, поэтому я написал это, чтобы не повторять то же самое, что пишут другие люди, потому что то же самое в конце до Последняя версия.

Это просто для того, чтобы сообщить Гэтсби, что многие люди все еще сталкиваются с проблемой и еще не исправлены.

Извините, если это вас беспокоит, но я обычный пользователь, использующий фреймворк, и у меня нет времени, чтобы решить проблему самостоятельно.

В моем случае это происходило только при добавлении префиксов к путям, поскольку я пытаюсь использовать gatsby-plugin-ipfs (запуск gatsby build --prefix-paths && gatsby serve приведет к появлению сообщения «Ошибка / ресурсы страницы для / не найдены. Не отображается React» для каждого страница).
Однако на моей странице index.jsx я не выполнял никаких запросов к странице, но у меня был компонент, содержащий staticQuery, из хука useStaticQuery.
Если бы я закомментировал этот компонент и перестроил, ошибка исчезла бы.
Интересно, что если я затем раскомментирую этот компонент и снова перестрою (так что сайт вернется в исходное состояние), то он будет работать нормально и не столкнется с ошибкой «Ошибка / ресурсы страницы для / не найдены. Не отображается реакция», предполагаете, что кеш сборки содержит что-то важное?

Итак, мои (грубые) мысли о том, почему это могло произойти:

• Проблемы с индексной страницей, содержащей статический запрос, но не запрос страницы?
• Проблемы с порядком процесса сборки (поскольку кеширование может изменить результаты).
• Потенциально проблема с run static queries или Generating image thumbnails в процессе сборки, поскольку это единственные шаги, которые кажутся пропущенными благодаря кешу.

Я случайно перенаправил данные страницы JSON в файл HTML

Аналогичная ситуация и здесь. По сути, регулярное выражение директивы nginx location также соответствовало /page-data/items/page-data.json хотя этого не должно было быть. Добавление ^ в начало регулярного выражения позволяет избежать непреднамеренного совпадения.

Мы видим это в производстве на https://www.voteamerica.com/. Это происходит в основном в Mobile Safari, но мы также наблюдаем это в Android Chrome, настольном Safari, настольном Chrome и других. В настоящее время мы используем Gatsby 2.21.40, но проблема возникла и в 2.20.12.

Также сталкивается с той же проблемой.

Привет, команда Гэтсби, всем привет. Можно ли указать ошибки, возвращаемые в loadPage который, кажется, является источником различных ошибок, обнаруженных в этой проблеме?

Ссылка на функцию: https://github.com/gatsbyjs/gatsby/blob/030d927cddbdc64f8d93d409a5ada7442d5e62bf/packages/gatsby/cache-dir/loader.js#L179 -L242

Насколько я понимаю, эта функция пытается загрузить app-data.json , page-data.json а затем сами компоненты JS, что очень подвержено проблемам с сетью, проблемам конфигурации сервера, проблемам разработки, проблемам конфигурации ... Указав сообщение об ошибке, будет легче исправить основные проблемы.

(Для справки: последний раз эта проблема на нашем веб-сайте возникла из-за циклического импорта)

Я попробовал еще раз с v2.23.12. Тот же результат: https://vermehrungch-1j64x2olp.vercel.app/Vermehrung

Нам это кажется абсолютно систематическим, поскольку каждая версия выше 2.20.36. В каждом из пяти приложений, созданных с использованием Gatsby. Таким образом, с тех пор нам заблокировали обновление.

Что начинает становиться проблемой. Например, нам запрещено использовать какие-либо библиотеки, использующие core-js в версии 3 (https://github.com/gatsbyjs/gatsby/issues/15601). Эта проблема теперь решена - если мы _согласно_ обновлению.

Если есть способ помочь с информацией / тестами / чем угодно, я бы с радостью помог.

@barbalex В вашем приложении произошла следующая ошибка:

Мы обязательно должны показать эту ошибку. Не стесняйтесь добавлять PR, у меня недостаточно пропускной способности для этого банкомата.

Похоже, что в нашем случае эта проблема вызвана реакцией-contextmenu, когда эта https://github.com/vkbansal/react-contextmenu/issues/284 , которая, похоже, срабатывает во время процесса сборки.

@wardpeet

Не стесняйтесь добавлять PR, у меня недостаточно пропускной способности для этого банкомата

Извините, но серых ячеек у меня для этого не хватает 😢
Может, @ b4stien умеет?

Проблема все еще сохраняется в версии 2.23.21.

У меня нет универсального решения для этого, но я просто хотел, чтобы было известно, что сегодня утром у меня впервые возникла эта проблема.

И мне удалось это «исправить».

Сайт размещен на AWS через провайдера Cloudways.

В качестве первоначального теста я развернул сайт на Netlify - и все работало нормально.

Немного покопавшись, похоже, возникла проблема с кешем на стороне сервера с использованием чего-то под названием «Varnish».

Сначала я попытался «очистить» его, но ничего не произошло - но отключение и повторное включение сработало.

Этот сайт просуществовал нормально около 18 месяцев в этой среде с регулярными обновлениями, и я впервые столкнулся с этой проблемой.

Недавно я обновился до:
Версия Gatsby CLI: 2.12.59

Не уверен, что это могло иметь какой-либо эффект, но это единственное изменение, о котором я могу думать - если, конечно, не было изменений на стороне хостинга.

Надеюсь, это кому-то поможет 🤷

РЕДАКТИРОВАТЬ:

Проблема вернулась в течение 5 минут, когда я снова включил кэш «лака».

Я отключил эту функцию сейчас.

В нашем случае каждая страница, созданная из папки /pages работает, но остальные, созданные createPages не реагируют на регидратацию.
Мы столкнулись с этой проблемой как в локальной, так и в CI.

в нашем случае все страницы созданы с помощью createPages , потому что мы используем интернационализацию с префиксом /${locale}/ каждой страницы.

в нашем случае все страницы созданы с помощью createPages , потому что мы используем интернационализацию с префиксом /${locale}/ каждой страницы.

вы нашли решение для этого? у нас также есть эта настройка со многими языками

@kdichev Нет, решения не нашел. Ожидание, что команда Гэтсби исправит это на уровне библиотеки.

Я все еще не уверен, в чем проблема, я бы с радостью устроил для этого пиар, но хотел бы, чтобы мы выяснили, где находится основная проблема?

Привет, ребята, я столкнулся с этой проблемой при использовании IE11.

"гэтсби": "^ 2.23.11"

Также отображается пустой (без гидратации) результат всех страниц в IE11.
Ресурсы страницы для / не найдены. Не реагирует на рендеринг

Гэтсби v2.24.2

РЕДАКТИРОВАТЬ: я вернулся к предыдущей действующей версии v2.22.11. ie11 работал в этом коммите, и правильно, поэтому он работал и сейчас, хотя только когда я сохранил package-lock.json и npm ci. Почему-то я не верю, что это Гэтсби ошибается, поэтому я перечисляю некоторые возможные последующие изменения, которые могут иметь значение:
(рабочая версия -> неудачная версия сборки)
большие, которые являются вероятными кандидатами только на отказ IE11:
@ babel / core 7.10.0 -> 7.10.5
@ ядро ​​/ js 2.6.11 -> 3.6.5
gatsby-legacy-polyfills новый dep 0.0.2

другое менее вероятно:
@ graphql-tools / schema новый деп 6.0.14
@ graphql-tools / utils новый деп 6.0.14
а затем мое терпение просеивать все красные-> все зеленые в инструменте vscode diff закончилось

Другие примечания: я воспроизвел ошибку с помощью gatsby build && gatsby serve -H 0.0.0.0, так что это исключает любые вещи на стороне сервера.

РЕДАКТИРОВАТЬ 2: Выходные данные сборки fauly v2.24.2, о которых впервые было сообщено в моем сообщении, увеличились с 10 МБ до 30 МБ. В нем около 20 версий app- {hash} .js, 2 обычных- {hash} .js и различное количество pages.js. Похоже, это не совсем те же файлы, и они датированы, чтобы соответствовать предыдущим сборкам. Похоже, что сборка gatsby каким-то образом заполучила все доступные старые версии и поместила их в / public.

Кто-нибудь может поделиться репозиторием?

@roffelsaurus можешь попробовать 2.23.22?
для нас 2.24.2 терпит неудачу в тестах ci / cd cypress.

Кто-нибудь может поделиться репозиторием?

мы можем поделиться нашим репо и варами в частном порядке, если вас это устраивает, пожалуйста, напишите мне по электронной почте на konstantin. [email protected] и я приглашаю вас в наш gh

@wardpeet, вы можете протестировать эту проблему в репозитории, к

В моем случае проблема была связана с порядком import и тем, как некоторые библиотеки (а именно react-leaflet ) обрабатываются в среде рендеринга на стороне сервера. У нас был импортированный плагин для листовки до самой листовки, что впоследствии вызвало проблему. Я смог исправить это довольно быстро, когда знал, где искать.

Однако я считаю, что созданное им сообщение об ошибке ( page resources for / not found. Not rendering React ) было невероятно запутанным, а отсутствие подробностей и других ошибок было основной проблемой, поскольку мне пришлось довольно глубоко копать, чтобы понять, что это вообще означает.

Всем, у кого есть эта проблема: как я ее нашел? Старая добрая точка останова и отладка в хроме. gatsby build && gatsby serve позволяет видеть производственную среду локально со всеми исходными картами. Мне удалось отладить, какой кусок, а затем компонент не загружается и возиться с импортом внутри. Это был довольно медленный процесс, так что наберитесь терпения, так как вы будете перезагружать страницу снова и снова. Найдите имя своего блока (в моем случае это было component---src-pages-index-js ) и назначенный ему импорт. Войдите в него и понаблюдайте за его зависимостями, поскольку один из них выйдет из строя. Я верю, что в каждом случае все будет по-своему, поэтому нигде нельзя найти одно хорошее решение. Исходные карты пригодились, поскольку они показали мне больше, чем просто серию общих обещаний в массиве.

Это не суть темы, но подробности того, что я выяснил, я оставлю ниже. Однако имейте в виду, что ниже указано только для листовок-ответов, и ваш опыт будет отличаться:

Итак, так было изначально:

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

и вот как это выглядит сейчас:

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

Конечно, это ошибка с нашей стороны, так как любой плагин обычно следует за библиотекой, к которой он подключен. Поскольку react-leaflet (я думаю) немного меняет порядок загрузки при запуске отладки, проблема не была видна во время разработки.

Я только что отлаживал Uncaught (in promise) Error: page resources for /app/ not found. Not rendering React в своем приложении. В моем случае / app / - это клиентский маршрут, содержащий приложение для реагирования. У меня не было проблем с gatsby develop , но я получал эту ошибку при запуске gatsby serve а также в производственной сборке. Об ошибках сборки не сообщалось.

Оказывается, проблемы были с response-contextmenu (https://github.com/vkbansal/react-contextmenu/issues/284), с которым также столкнулся

@rgembalik , я отлаживал это, удаляя все компоненты из моего компонента приложения, а затем добавляя их по одному, пока я не нашел компонент, который нарушал сборку.

Для меня я даже не могу воспроизвести, я просто вижу множество тезисов ошибок в отчетах об ошибках часового. так что не уверен, как я выясню

Мы получаем много таких ошибок в Sentry с этими ошибками, а также для всех типов страниц, кроме "/", которые также не могут быть воспроизведены. Размещено на Netlify. Я подозреваю, что это может иметь какое-то отношение к активным сеансам во время развертывания, но это трудно проверить.

@wardpeet кажется, что есть много разных потенциальных причин, которые вызывают эту же ошибку. Мы видим эти ошибки только в нашем журнале Sentry и никогда не могли их воспроизвести. Можно ли включить в ошибку дополнительную информацию или добавить несколько более детализированных ошибок, чтобы у всех нас было что-то еще, чтобы попытаться найти причину?

Я только что получил эту ошибку на https://www.gatsbyjs.com/, заканчивая пустой страницей

Я могу подтвердить, что при первой загрузке страницы я видел эту ошибку на gatsbyjs.com

Я понял, что у Гэтсби есть особый способ обработки URL-адресов с конечными косыми чертами. Я не знаю, может ли это помочь

У меня тоже есть эта проблема.

Я не могу поделиться репозиторием, но если вы перейдете на эту страницу, вы увидите, что она правильно загружает SVG. Но если я перейду к несуществующему маршруту, например https://rocketseat.com.br/test, он отобразит устаревшую версию кода (который все еще использует gatsby-image вместо SVG) и покажет мне это сообщение на консоли:

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

Я использую [email protected]

_edit: я не знаю почему, но после того, как я добавил здесь свою проблему, проблема с изображением была решена, но я продолжаю получать ту же ошибку на странице console_

Мне трудно воспроизвести, я просто вижу тонну этих ошибок в отчетах об ошибках часового

@theskillwithin - то же самое. Тысячи таких в Sentry.

У меня такая же проблема. Очень странный. Похоже, эта ошибка вызывается разными причинами.

Мы также наблюдаем, что эта ошибка возникает в разных браузерах и на разных страницах. Кажется, я не могу связать нашу ситуацию ни с одной из вышеупомянутых возможных причин. К тому же я не могу воспроизвести в разработке - это происходит только с нашим развернутым веб-сайтом.

У меня такая же проблема. не в состоянии воспроизвести, но тонны этих ошибок в карауле. также множество браузеров
гэтсби версия 2.24.3

Об этом довольно часто сообщают на производственном сайте, где я тоже использую Sentry. Невозможно воспроизвести себя. На мой взгляд, нам нужно улучшить отчетность. Что в этом странного, так это то, что он действительно находит данные страницы:

Поскольку он получает статус 200 и AFAICT, json не имеет неправильного формата, я предполагаю, что fetchPageDataJson() возвращает успешный ответ:
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L137 -L151

Поскольку это кажется успешным, следующей точкой отказа, которую я вижу, будет загрузка самого компонента:
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

Возможно, есть проблема в выписываемых async-requires . Я полагаю, что это на самом деле нормально, поскольку они будут обрабатываться Webpack, и проблема, похоже, временная. Если возникла проблема с записью этого файла, сборка провалилась бы.

Если бы это была какая-то проблема с синтаксисом где-то в импортируемом модуле, то я полагаю, что она выйдет из строя 100% времени. Возможно, в модуле используется что-то, несовместимое с каким-либо устройством / браузером, загружающим указанный модуль. Трудно сказать наверняка, поскольку конкретная ошибка скрывается.

Я думаю, что нам нужен загрузчик компонентов, чтобы _не_ поглотить генерируемую ошибку.

Наличие Promise.resolve() там, когда чанка не существует в asyncRequires означает, что возникшая ошибка имеет смысл. Эта ошибка также будет выдаваться при каждом посещении этой страницы ... поэтому было бы легко отследить причину.

Возврат null в блоке catch означает, что выданная ошибка не имеет смысла. Модуль был найден, но при динамическом импорте произошла ошибка. Разве webpack не возвращает ошибку в блоке catch() динамического импорта? Если это не так, возможно, это проблема, которую следует решить с помощью Webpack. Я знаю, что если я запустил плохой import() из devtools, появится сообщение об ошибке ... сообщается ли сообщение об ошибке на основе неспособности / невозможности синтаксического анализа импортируемого javascript - это другой вопрос, и это займет дополнительное тестирование с использованием кода, который я _ знаю_, не будет работать в некоторых браузерах.

@wardpeet вы упомянули более отчеты об ошибках ранее . Это в разработке или нужна помощь?

Что касается совместимости браузеров, я вижу, что эти ошибки в основном генерируются мобильными устройствами.

Но я также видел эти ошибки, сгенерированные в MacOS X с использованием Safari и Windows 10 с использованием Chrome.

Одна общая черта заключается в том, что трафик, как правило, исходит из Facebook или Google. Но это может быть просто совпадением, поскольку именно они привлекают большую часть нашего трафика.

_ПРИМЕЧАНИЕ: этот сайт, с которым я работаю, на самом деле использует [email protected] , поэтому код, на который я ссылаюсь, находится в разных местах, но сама логика, похоже, не изменилась. Он по-прежнему делает то же самое, и потенциальные точки отказа, которые я определил, похоже, те же самые.

[email protected]

Я также нечасто вижу ошибку на bugsnag. Неясно, отображается ли страница мне или нет. Вот стек на bugsnag, если это поможет @wardpeet Интересно, что в этом случае, похоже, он

Я добавлю дополнительную информацию к зарегистрированной ошибке, так что, надеюсь, мы сможем найти проблему

У меня такая же проблема со страницей, на которой возникла другая ошибка, размещенная по адресу https://github.com/gatsbyjs/gatsby/issues/26706.

В моем случае это происходит (по крайней мере) в настольном Chrome, и это происходит только при первой загрузке страницы, если я нажимаю обновить, все отображается, как ожидалось

Затем, если я попытаюсь воспроизвести это в первый раз, даже в режиме incognito и пытаюсь стереть каждый кеш, о котором я могу думать, я не смогу (иногда мне удавалось, хотя и очень случайно), пока через некоторое время ( несколько дней) Я посещаю URL-адрес и обнаруживаю ту же ошибку (которая исчезает после повторного обновления)

Если я попытаюсь воспроизвести его с тем же минимальным репо, которое я использовал для указанной выше связанной проблемы, я не смогу увидеть те же ошибки (по крайней мере, не в тех случаях, когда я пробовал сейчас)

Ошибка (в данном случае) видна из-за того, что каменная сетка не создается, что в моем случае уничтожает страницу, если пользователь не думает об обновлении страницы (я подозреваю, что они этого не делают)

На самом деле это кажется таким случайным, что я видел это несколько недель, но всегда думал, что это что-то с моим компьютером

Я запустил npm auidit fix и проблема была решена для меня.

Следующий! Есть такая же проблема

Всем привет,

У нас тоже есть эта проблема только в производственной среде. Мы воспроизводим эту ошибку в 100% случаев на определенных URL. Давайте рассмотрим древовидную структуру нашего каталога public :

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

Когда мы вводим эти URL-адреса https://domain.com/usages/brainstorming он работает отлично, https://domain.com/usages/seminaries тоже. Если мы вводим неизвестный URL-адрес, например https://domain.com/doesnotexist у нас по праву есть страница 404, но если мы попытаемся достичь URL-адреса, который соответствует реальной папке в дереве, например https://domain.com/usages , у нас будет эта пустая страница и эта ошибка.

Это может быть для вас звонком?

Лучший

@guillaumepotier, а вы тоже используете nginx?

Я думаю, это может быть вызвано ошибочными заголовками ответов.

@ daydream05 да, действительно, мы используем nginx. Мы видели в наших журналах около 304 заголовков «Не изменено», а иногда и 200 ответов.

с использованием ведра AWS S3

То же самое, хостинг в AWS S3 (с CloudFront CDN).

Я запустил npm audit fix и проблема была решена для меня.

Интересно @ liuuuk311. Я попробовал это в нашем проекте, и, возможно, это тоже решило проблему для нас. Время покажет, но пока что после 48 часов в наших журналах не было никаких событий.

Изменить: 5 дней спустя, по-прежнему нет происшествий ...

Изменить: 10 дней спустя, и это повторилось несколько раз, извините за сообщение. Сам по себе запуск npm audit fix , похоже, не решает проблему.

@wardpeet дополнительные данные об ошибках, которые могут помочь в диагностике ...

Согласно им, похоже, что файлы page-data.json действительно загружаются правильно ...

• так как я наткнулся на это сегодня, я наткнусь * и посмотрю здесь.

В моем случае я исправил проблему с загрузкой библиотеки polyfill.io на страницу

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

@pedrofsantoscom, объясните, пожалуйста, как статически загружаемый скрипт решает проблему с gatsby.js?

Вчера была такая же проблема. Очистка кеша локально исправила это для текущего пользователя. Итак, мы очистили кеш Cloudflare, и теперь мы больше не получаем никаких отчетов.
Очистка кеша была нашим решением

Мы не используем Cloudflare, мы используем AWS Cloudfront CDN, и он становится недействительным после каждого развертывания. Я столкнулся с ошибкой локально, запустив локальный веб-сервер с https с первой попыткой запуска после запуска веб-сервера, а также при некоторых последующих перезагрузках страницы, но не каждый раз. Я не вижу никакой закономерности. Просто это случается время от времени.

Мы не используем Cloudflare, мы используем AWS Cloudfront CDN, и он становится недействительным после каждого развертывания. Я столкнулся с ошибкой локально, запустив локальный веб-сервер с https с первой попыткой запуска после запуска веб-сервера, а также при некоторых последующих перезагрузках страницы, но не каждый раз. Я не вижу никакой закономерности. Просто это случается время от времени.

Это было для нас решением. Когда мы очищали кеш, количество ошибок в час уменьшалось быстро, и мы не получали ту же ошибку, по крайней мере, в bugsnag. Это действительно странная ошибка.

У меня было такое же сообщение об ошибке, но только в Internet Explorer. Все остальные браузеры не отображали такое сообщение об ошибке.

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

Я проследил проблему до импорта, который я сделал в своих компонентах реакции. В некоторых случаях у меня были зависимости от https://sap.github.io/ui5-webcomponents/ . Как только я удалил эти зависимости, проблема исчезла. Я не могу объяснить, какова настоящая основная причина, но хочу указать, что зависимости в ваших элементах управления реакцией могут вызвать эту проблему.

@Chaosbohne не может с этим поспорить, но я бы даже сказал, что это проблема суб-зависимостей. Думаю, тогда команда gatsby.js позаботится об управлении зависимостями и безопасности, и на первом этапе удалит ^ из всех версий dependency / devDependency, что позволит предотвратить целый ряд проблем.

Могу сказать, что эта проблема не зависит от браузера. Я видел это в Chrome и Safari на основе журналов Sentry, и в chrome 85, 86 локально на моем Mac.

Ни одно из решений не работает. @KyleAMathews из-за этой проблемы мы теряем бизнес, в течение 3-4 дней эта проблема возникает, и мы не можем выяснить ее основную причину. Пожалуйста, помогите нам найти решение этой проблемы.

@ R3coN вы пытались перестроить свой сайт? Когда это случилось с нами, мы просто попробовали снова (это было некоторое время назад, я не могу вспомнить, почему это было исправлено)

@ R3coN, если это может помочь, вот версии пакетов, которые мы используем, которые работают нормально:

    "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 да, это единственный способ исправить это - заново версию Gatsby CLI: 2.12.67 и версию Gatsby: 2.24.47, поскольку вы упомянули, что версия 2.20.36 gatsby отлично работает для вас, мы попытаем счастья, понизив версию gatsby.

@ shide1989 Спасибо за комментарий. Но понижение версии вызывает у меня эту ошибку ->

WebpackError: не удалось получить результат этого StaticQuery.

Что работало в предыдущей версии 2.24.47.

жаль это слышать, возможно, вам не хватает литерала шаблона с тегами graphql в том же файле, где для извлечения запросов во время сборки используется ловушка useStaticQuery. (как описано здесь: https://github.com/gatsbyjs/gatsby/issues/24526)

в любом случае удачи с этим

Но я сказал вам, что тот же код работал для gatsby 2.24.47.

@ R3coN эта проблема также может быть вызвана неправильным статическим кешированием. Если вы используете nginx или s3 для своего сервера и не аннулируете свой page-data.json, тогда ваш StaticQueries будет ломаться всякий раз, когда вы меняете свои данные.

У меня была эта проблема, и оказалось, что я кэшировал весь файл page-data.json. Не должно быть. Их необходимо повторно проверять при каждом запросе.

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

@ daydream05 Спасибо за комментарий. Да, я использую S3 с CloudFront. У вас есть идеи, как этого добиться с помощью Cloudfront?

@ daydream05 У меня уже есть cache-control: 'public, max-age = 0, must-revalidate' добавлено в page-data.json и app-data.json, что означает, что эти страницы не кэшируются.

Я вижу это также на несуществующих страницах (которые должны загружать и увлажнять страницу 404).

Локально мои разработки и производственные сборки работают без этой ошибки, и когда я вставляю console.log во время проверки, которая выдает эту ошибку в построенном продукте app-[hash].js , я вижу, что page object существует и включает page.componentChunkName: ""component---src-pages-404-js" как я и ожидал.

Однако, когда приложение развертывается в облаке gatsby, ошибка возникает при каждой загрузке несуществующей страницы. Страница SSR'd 404 отображается в браузере, но затем выдается ошибка, поэтому React никогда не запускается в браузере. Когда страница 404 загружается напрямую (путем посещения пути /404 ), она работает нормально, без ошибок.

Это сложно диагностировать, потому что мне пока не удалось воспроизвести это локально.

Используется последняя версия: "gatsby": "^2.24.91"

Просто разместите это здесь, чтобы другие пользователи могли использовать react-md для быстрого исправления своего сайта, или надеетесь, что это может помочь в любом случае решить эту проблему в Gatsby.

У меня была такая же ошибка в одном из моих проектов, где я использовал react-md
После удаления всех компонентов я смог избавиться от проблемы.

Так как мне приходилось каждый раз развертывать в prod, чтобы проверить это, мне не удалось точно определить, какой конкретный компонент имеет эту проблему, но я сузил ее до.

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

Я буду обновлять сообщение в блоге об этой проблеме, если у меня будет время копнуть глубже.

Что касается 404 страниц, я могу подтвердить проблему @aMoniker , поскольку у меня

Локально и разработка, и производственная сборка отлично работают со страницей 404 , но при развертывании в Gatsby Cloud проблема возникает на каждой неизвестной странице, кроме фактического пути /404 .

Я также столкнулся с этой ошибкой и исправил ее, очистив кеш браузера. Однако было бы хорошо найти решение, которое не требует этого, поскольку мы не можем заставить все наши пользователи делать это.

@ dejavu1987, мы не используем возникла эта проблема.

@MaciekBaron Я воспроизвел ошибку локально, очищая кеш браузера несколько раз и перезагружая страницу после каждой очистки.

Похоже, это проблема кеширования, как я упоминал ранее. Если все заголовки кеша настроены правильно, проблема может быть в сервисных воркерах.

Может быть, попробовать этот плагин?
https://www.npmjs.com/package/gatsby-plugin-remove-serviceworker

Эй, я тоже столкнулся с этой проблемой. При разработке все работает нормально, но когда я запускаю сборку gatsby и развертываю общедоступный каталог в моем веб-хостере, страница не работает из-за этого сообщения об ошибке.

Мне было очень любопытно, и я заглянул в общедоступный каталог данных страницы. Я обнаружил, что конкретный каталог страниц существует, но он не был написан маленькой буквой, а каталог был написан заглавной буквой. Это была проблема, у меня сообщение об ошибке.

После этого я изменил его на маленькую букву в начале, и он нормально работал в прод. Я думаю, это происходит из-за того, что я ранее изменил имя страницы и, может быть, здесь что-то кешируется?

Я тоже сталкиваюсь с этой проблемой. Я нашел способ решить эту проблему. Но я думаю, что это не решило истинной проблемы.

Теперь позвольте мне объяснить, как это исправить.

Эта проблема была обнаружена в тестовой или производственной среде ，, как сказано выше, она не будет воспроизводиться в процессе разработки. Даже при тестировании или производстве это происходило не каждый раз. И я обнаружил, что все сценарии были предварительно загружены и выполнялись асинхронно. Так что я предполагаю, что это может быть вызвано исполнительным порядком сценариев.

Поскольку я замедляю сеть в сети, например, устанавливаю 3G fast , проблема возникала почти каждый раз. Это подтвердило мою догадку.

Чтобы подтвердить свое предположение, я изменил процесс рендеринга HTML в gatsby-ssr.js чтобы установить все скрипты без "асинхронности" , как показано ниже:

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

К счастью, это работает.

Несмотря на то, что этот способ может помочь решить проблему, я не думаю, что это хороший способ сделать это. Похоже, нарушая особенность Гэтсби. Скрипт выполняется асинхронно, как это?

Надеюсь, этот способ решит и все ваши проблемы.

Эта проблема была обнаружена в тестовой или производственной среде ，, как сказано выше, она не будет воспроизводиться в процессе разработки. Даже при тестировании или производстве это происходило не каждый раз. И я обнаружил, что все сценарии были предварительно загружены и выполнялись асинхронно. Так что я предполагаю, что это может быть вызвано исполнительным порядком сценариев.

Несмотря на то, что этот способ может помочь решить проблему, я не думаю, что это хороший способ сделать это. Похоже, нарушая особенность Гэтсби. Скрипт выполняется асинхронно, как это?

Я думаю, вы правы, у меня эта проблема возникла по странным причинам.
Последний был безумным, но когда я связываю его с вашим ответом, он становится понятным.

Итак, недавно я добавил компонент значка шрифта в свой компонент макета, и он воспроизвел эту проблему.
Важно отметить, что значки шрифтов все это время использовались в других глубоко вложенных компонентах, и это никогда не вызывало проблем, только когда они находились на уровне макета, который является первым компонентом, вызываемым из любого компонента страницы.

Я могу ошибаться, но это может быть хорошим сценарием для выяснения истинной причины.

@ dejavu1987 Согласен с вами. Возможно, вы дали хороший сценарий, чтобы выяснить настоящую причину.

Кроме того, мне интересно, подходит ли загрузка и выполнение сценариев с помощью async , поскольку коды webpack разделяют на разные части, но эти части могут иметь зависимости.

Основная проблема, похоже, заключается в том, что Гэтсби проглатывает ошибки во время загрузки страницы и просто сообщает очень общее сообщение page resources for / not found. Not rendering React , поэтому в этой ветке сообщается так много разных потенциальных причин.

Моя проблема заключалась в том, что Mobx 5 не поддерживает IE11, и хотя Mobx предоставляет для этого красивое сообщение об ошибке, все, что я получил, это сообщение «ресурсы страницы не найдены» от Гэтсби, которое вводило в заблуждение.

Я смиренно предлагаю в качестве решения этой проблемы сообщить об исходном сообщении об ошибке, которое привело к сбою загрузки страницы. @wardpeet

Что исправило для меня, так это то, что у меня был настроен S3, чтобы возвращать 200 на странице 404. Когда я изменил его, чтобы вернуть код состояния 404, он работал.

Да, я тоже это нашел. Однако моя проблема была шире… Я неправильно кэшировал результаты Cloudfront 404. Причина, по которой я получал 404 результата между Cloudfront и S3, заключается в том, что развертывание на S3 через CodePipeline, как я полагаю, распаковывает ZIP-файл Build Artifact, но не в каком-либо определенном порядке. Итак, в течение нескольких минут у вас могут быть новые файлы .HTML, указывающие на новые файлы .JS (с новыми хешами), которых еще нет. Независимо от того, что обрабатывает кеширование ваших хешированных файлов ресурсов, не должно кешировать результаты 404, поскольку это можно исправить только путем очистки вашего кеша CDN.

Кстати, кто-нибудь придумал, как убедиться, что файлы HTML развертываются на S3 в последнюю очередь?

Дэвид
https://ewebinar.com

21 октября 2020 г. в 12:40 Винс П. [email protected] написал:

@ R3coN https://github.com/R3coN эта проблема также может быть вызвана неправильным статическим кешированием. Если вы используете nginx или s3 для своего сервера и не аннулируете свой page-data.json, тогда ваш StaticQueries будет ломаться всякий раз, когда вы меняете свои данные.

У меня была эта проблема, и оказалось, что я кэшировал весь файл page-data.json. Не должно быть. Их необходимо повторно проверять при каждом запросе.

https://www.gatsbyjs.com/docs/caching/ https://www.gatsbyjs.com/docs/caching/
-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/gatsbyjs/gatsby/issues/19618#issuecomment-713298516 или откажитесь от подписки https://github.com/notifications/unsubscribe-auth/AA3SHT55MXZTXQUAXH5ZU4VJANCNZ5

Могу добавить, что я воспроизвел проблему с Chrome Lighthouse Audit при тестировании мобильных устройств, с тестами PWA и без них. Я уверен, что в мобильных тестах используются ограничения сети и процессора, поэтому асинхронные скрипты загружаются не по порядку или один из 30 сбой ... может быть довольно частой ситуацией.

Я работаю с 3D, и даже при localhost с webpack и gatsby.js перезагрузка страницы довольно часто приводит к сбоям сетевых запросов для статической модели gtlf файлы. Один из них вышел из строя - все приложение не работает (если не установлен ErrorBoundary).

Думаю, здесь может быть тот же шаблон, но без надлежащей обработки ошибок.

Я использую S3 и CloudFront для производства. У меня была аналогичная проблема, но в моем случае я получал ошибку Can't render React в консоли только на Cloudfront. Это стало происходить после изменения файлов на производственном S3. К моему удивлению, проблема решена после перезапуска маяка на производство.

Это происходило только на моем устройстве в обычном режиме. В моем случае очистка всего кеша, файлов cookie, локального хранилища, хранилища сеансов и сервис-воркеров раньше не помогала.

Поэтому, если вы профилируете свое производственное происхождение с помощью lighthouse и файлы были изменены, эта проблема также может возникнуть (в моем случае это было)

Я хочу сказать, что я могу воспроизвести это с помощью lighthouse примерно 1 из 10, а последнее развертывание было давно.

Я не думаю, что Гэтсби сможет решить эту проблему, потому что это происходит со всеми, но причина в другом. Я слишком часто получаю пустые страницы или всякий раз, когда я что-то меняю, страница backend gatsby становится пустой и выдает ошибку, и эта ошибка тоже каждый раз разная. Я думаю, нам нужно перестать использовать gatsby и перейти на какой-нибудь другой надежный фреймворк.

Я мог бы исправить ошибку, если есть способ воспроизвести ее, но его нет. Эта ошибка возникает случайным образом, иногда через день после развертывания, иногда через 3-4 дня после развертывания. Но бывает.

@antoinerousseau Вы что-нибудь нашли? Может кто-нибудь подскажет пошагово, как хоть эту проблему отладить? Я перепробовал все со своей стороны, но через 1-2 дня после развертывания сайт ломается. Может ли кто-нибудь сказать мне, как узнать, когда возникнет эта проблема, потому что для меня это происходит слишком случайно?

Что исправило для меня, так это то, что у меня был настроен S3, чтобы возвращать 200 на странице 404. Когда я изменил его, чтобы вернуть код состояния 404, он работал.

S3 или Cloudfront?

В моем случае проблема была на странице 404, используемой по умолчанию в Azure. Это была ошибка блокировки, и единственное, что я смог увидеть в консоли, это
Error / page resources for / not found. Not rendering React

С тех пор, как я начал использовать кастомный 404 - проблема исчезла.

Я получаю то же самое, когда развертываю приложение на Netlify .. Локально Gatsy Build и Gatsby Serve работают хорошо .. Это еще более странно ..

@atapas, не могли бы вы связаться со службой поддержки Netlify? может быть они могут что-то уточнить со своей стороны?

@atapas, не могли бы вы связаться со службой поддержки Netlify? может быть они могут что-то уточнить со своей стороны?

Да, я сделал. Благодаря!

Возможно, здесь были бы полезны более точная трассировка стека или четкое сообщение об ошибке. В любом случае, спасибо за ответ.

@atapas Я не являюсь членом команды, просто страдаю той же ошибкой, что и вы.

Я получаю то же самое, когда развертываю приложение на Netlify .. Локально Gatsy Build и Gatsby Serve работают хорошо .. Это еще более странно ..

Я нашел решение в совершенно другом контексте. Я получал сообщение об ошибке, потому что Netlify игнорировал переменные env, которые я установил для Auth0 для работы в моем приложении,

домен: process.env.AUTH0_DOMAIN,
clientID: process.env.AUTH0_CLIENTID,
redirectUri: process.env.AUTH0_CALLBACK,

Позже я прочитал отсюда о «Развертывании без чувствительных переменных» и исправил это, как было упомянуто в документе.

Я удивлен полученной ошибкой, и решение попало в ... но рад, что это сработало.

@atapas Я не являюсь членом команды, просто страдаю той же ошибкой, что и вы.

@ JustFly1984 , не волнуйтесь, я очень хотел вас поблагодарить. Я заглянул в документ Netlify и смог найти решение, упомянутое в приведенном выше комментарии.

У меня такое только в Хроме. Safari отлично работает. Я только что добавил в свой проект плагины offline и manifest. Я не могу воспроизвести его с помощью Gatsby develop или gatsby build & gatsby serve локально. Я принимаю хостинг на Netlify.

Для меня этот блок кода вне моего компонента React, а также ссылка на глобальные переменные в компоненте React вызывали ошибку. Его удаление устранило проблему.

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