Как локализовать ошибку бесконечного спиннера и определить сторону ошибки?

Что проверяют

Умеете ли вы идти от симптома к причине по шагам, а не заводить баг «крутится спиннер». Главное: понять, чья зона, фронта или бэка, и приложить к отчёту доказательства. Следом спрашивают, как оформить такой баг и что делать, если он воспроизводится не всегда.

Как отвечать

Каркас: воспроизвести, открыть DevTools, найти запрос, которого ждёт спиннер, и выяснить, что с ним случилось.

• Network: включить Preserve log и найти запрос. Он не ушёл вовсе, значит ошибка на клиенте до отправки. Висит в pending: сервер или шлюз не отвечает, нет таймаута. Вернул 4xx или 5xx, а интерфейс не обработал ошибку. Вернул 200, но тело не того формата;
• Console: необработанное исключение в JS после ответа часто оставляет состояние «загрузка» навсегда;
• сверка с контрактом: ответ сравнивается со Swagger или OpenAPI. Пришёл null там, где ждут массив: ошибка на бэке, но и фронт виноват, что не показал сообщение;
• запрос в обход интерфейса: Copy as cURL, Postman. Если напрямую сервер отвечает нормально, проблема на клиенте;
• подмена ответа: Charles, Fiddler или Overrides в DevTools. Отдайте фронту корректный или заведомо ошибочный ответ и посмотрите на реакцию;
• логи бэкенда: по request id или trace id найти запрос в Kibana, Grafana или аналогах;
• условия: троттлинг сети, другой браузер и учётка, чистый кеш. Бесконечная загрузка на медленной сети это отдельный баг про отсутствие таймаута.

В баг-репорт: шаги, окружение, HAR или скрин запроса с кодом и телом ответа, ошибка из консоли, id запроса и время. Тогда разработчику не придётся переспрашивать.

Где спотыкаются

Видят статус 200 и делают вывод «бэк в порядке», не открыв тело ответа.

Пишут «ошибка на фронте» только потому, что спиннер на фронте. Ответ, который так и не пришёл, это вопрос к серверу или сети.

Не проверяют воспроизводимость и не фиксируют условия. Плавающий баг без HAR, времени и id запроса почти никто не станет искать.