Как искать причину, если в Postman ответ 200, а с фронта 500
Что проверяют
Умеете ли вы локализовать дефект, а не пересылать его между командами. Интервьюер ждёт, что вы начнёте со сравнения двух запросов, а следом спросит, чей это баг и что вы напишете в отчёте.
Как отвечать
Исходная мысль: 500 это ошибка сервера, но раз Postman получает 200, запросы чем-то различаются. Задача найти, чем именно.
- снять запрос фронта: во вкладке Network в DevTools найти упавший запрос, скопировать его через «Copy as cURL» и импортировать в Postman. Если в таком виде он тоже даёт 500, дальше сужаете разницу, убирая заголовки и поля по одному;
- заголовки:
Content-Type(фронт может слатьmultipart/form-dataилиtext/plainвместоapplication/json),Authorization, куки,Accept-Language. Токен в Postman часто принадлежит другому пользователю с другими правами и данными; - тело:
nullпротив отсутствующего поля, число строкой, другой формат даты, лишнее поле, которого сервер не ждёт; - адрес и окружение: фронт может ходить на стенд с другой версией бэкенда или через прокси, gateway или BFF. Тогда 500 отдаёт промежуточное звено, а не сам сервис;
- соседние вызовы: иногда падает не основной запрос, а preflight
OPTIONSили предыдущий вызов, от которого зависит этот; - логи: по времени, пути или
X-Request-Idнайти ошибку в Kibana, Loki или Sentry, там обычно видно исключение и место падения.
В отчёт идут оба запроса в виде cURL, найденная разница, фрагмент лога и окружение. Отдельно отметьте, что на некорректный ввод сервер должен отвечать 4xx, а не 500.
Где спотыкаются
Сразу объявляют «баг на фронте». Даже если фронт шлёт кривые данные, 500 означает, что сервер не валидирует вход, и это второй дефект, который тоже нужно завести.
Сравнивают запросы на глаз, а не копируют реальный из браузера. Разница в одном заголовке или лишний пробел в токене так теряются.
Проверяют в Postman другой стенд или другого пользователя и делают вывод, что «на бэке всё работает». Сравнение имеет смысл только при одинаковых окружении, учётной записи и данных.