Как определить виновника проблемы, если при клике не происходит ничего: фронт или бэк

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

Умеете ли вы за пару минут отделить проблему фронта от проблемы бэка с помощью DevTools, а не гадать. Следом обычно спрашивают: запрос вернул 200, а на экране ничего не изменилось, чья это ошибка?

Как отвечать

Откройте DevTools до клика и включите на вкладке Network опцию Preserve log, чтобы запросы не пропали при перезагрузке страницы. Дальше идите по развилкам:

• запрос не ушёл: вероятнее всего фронт. В Console ищите исключение, оно останавливает всё, что идёт после него. Проверьте, что кнопка не disabled и её не перекрывает прозрачный слой, а на вкладке Event Listeners видно, повешен ли обработчик. Ещё вариант: клиентская валидация молча блокирует отправку;
• ответ 5xx: вероятнее бэк. Берите время и trace id и ищите запрос в логах сервера или в Sentry;
• ответ 4xx: здесь внимательнее. 400 или 422 часто значат, что фронт отправил не то, сверьте тело запроса с контрактом в Swagger. 401 и 403 это авторизация и права;
• 200, но экран не меняется: откройте Response. Если данные верные, фронт их не применил. Если в теле {"success": false} или пустой список, разбираться с бэком;
• запрос висит или помечен как CORS error: таймаут на сервере или неверные CORS-заголовки, это настройка бэка или прокси.

Решающая проверка: скопируйте запрос через Copy as cURL и повторите его в терминале или в Postman. Если вне браузера сервер отвечает корректно, проблема на стороне клиента.

В баг-репорт прикладывайте HAR-файл, текст ошибки из консоли, cURL и версию браузера.

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

Делают вывод только по статусу. 200 не означает успех, если сервер кладёт ошибку в тело, а 400 часто оказывается виной фронта.

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

Забывают про Preserve log. Кнопка отправляет форму, страница перезагружается, Network очищается, и кажется, что запроса не было вовсе.