Почему PWA на основе реагирования, размещенное в моей службе приложений Azure, случайно начинает возвращать ошибку 500 для ВСЕХ вызовов POST (GET работает нормально)? Исправлено: Перезапустить браузер?

Предыстория проблемы У нас есть PWA на основе реагирования (версия 16.14.0), размещенное в планах обслуживания приложений Microsoft Azure (уровень «Премиум»).

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

Случайным образом при подключении к приложению мы замечаем сетевые ошибки: на одном (или более) из трех возможных серверов, с которыми взаимодействует пользовательский интерфейс, будет отображаться ошибка 500. В этом «состоянии» ВСЕ ошибки POST не дойдут до этого конкретного бэкэнда.

Это влияет ТОЛЬКО на конечные точки POST. Конечные точки GET успешно продолжают работать с этими серверами (что исключает проблемы с DNS). ВСЕ конечные точки POST возвращают 500 (было одно исключение POST-запроса, но мы пришли к выводу, что это произошло из-за отсутствия полезной нагрузки!). Запросы OPTIONS (предварительные проверки) для этих запросов POST успешно возвращают 204, но фактический запрос получает 500.

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

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

Это влияет на все наши серверные части. Серверная часть пользовательского интерфейса и C# .NET Framework 4.8.1 размещена в одном плане службы приложений, и здесь мы наблюдаем такие сбои время от времени. Пользовательский интерфейс также не работает с двумя другими службами приложений, размещенными в .NET 8 (которые работают в том же плане службы приложений).

Получена ошибка браузера: Не удалось загрузить ресурс: net::ERR_FAILED.

У меня два вопроса... Во-первых, почему это влияет только на POST? Я надеюсь, что понимание этого поможет определить основную причину проблемы. Во-вторых, как вы думаете, это могло быть из-за фронтенда, вызванного 500? Я видел доказательства того, что некоторые вещи в реакции (например, реагирующий маршрутизатор) могут возвращать 500. Я всегда думал, что ответ 500 ДОЛЖЕН прийти от серверной части. Но на данный момент я в этом не уверен, поэтому прошу некоторых разъяснений.

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

Заранее большое спасибо за любые вопросы, предложения и ответы.

Что мы попробовали:

1. Отключение кеша браузера через инструменты разработчика Chrome
2. Обход опции Network Chrome для сервисного работника
3. Перезапуск серверной службы приложений — проблема не устранена
4. Различные браузеры (также влияет на Firefox)
5. Старые версии Chrome (по результатам тестов селена)
6. Fiddler — мы видим запрос 500 в Fiddler
7. Обновление пакета axios до последней версии
8. Перенос вызовов серверной части JavaScript из xhr для извлечения
9. Установка кэша без сохранения для запросов на выборку
10. Исключены проблемы с Cors, потому что мы также видим эту ошибку на сайте того же происхождения (и если бы это был Cors, он всегда давал бы сбой, а не только случайно).
11. Очистка всех данных сайта, файлов cookie, кеша и выполнение жесткой перезагрузки кеша.
12. Использование тех же заголовков http, тела, файлов cookie и т. д. через почтальона - работает нормально.
13. Попытка определить, КОГДА проблема началась - по крайней мере, 3 месяца назад, но за последние несколько недель она стала гораздо более регулярной.
14. Затрагивает несколько регионов в Azure. Мы видим эту проблему как в инфраструктуре, размещенной в Северной Европе, так и в инфраструктуре, размещенной в Южной Великобритании.
15. Влияние на пользователей из разных географических регионов (у нас есть тесты селена, которые проводятся на западе США и подключаются к нашему сайту на юге Великобритании, и они также видели эти случайные сбои)

То, что нам еще предстоит попробовать, но есть в списке:

1. Миграция из службы приложений Windows на серверную часть на базе Linux (kestral) для серверных частей .NET 8, если это проблема IIS.
2. Очистить кеш Redis всех токенов удостоверения.
3. Обновление реакции и всех пакетов npm (масштабная задача)

Что может «исправить» ошибку? Перезапуск браузера Подождите X минут, что, по-видимому, составляет от 5 до 15 минут (я все еще пытаюсь определить, как долго длится X). Используйте другой сеанс браузера (например, откройте Chrome в режиме инкогнито).