Как диагностировать ошибку 500, если данные не сохраняются в базе данных?

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

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

Как отвечать

Идите от клиента к базе:

• воспроизведение: зафиксируйте шаги, данные и стенд. Проверьте другие данные: если 500 только на длинном имени или эмодзи, половина работы сделана;
• запрос и ответ: во вкладке Network в DevTools посмотрите тело, заголовки и ответ. Повторите запрос в Postman или через curl, чтобы исключить фронтенд. Если в ответе есть id запроса, сохраните его;
• логи: по времени или id найдите запись в Kibana, Grafana Loki, Sentry или в логах контейнера (docker logs, kubectl logs). Стектрейс обычно называет причину: нарушение NOT NULL или уникальности, слишком длинное значение для varchar, таймаут соединения с базой;
• база: через SELECT проверьте, не записалось ли что-то частично, есть ли нужная колонка и накатана ли миграция на этом стенде;
• сравнение: воспроизводится ли на другом стенде и на прошлой версии. Если нет, ищите разницу в конфигурации или в последнем релизе.

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

В баг-репорт идут шаги, тело запроса, ответ, id запроса, время, стенд и фрагмент лога.

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

Сразу заводят баг «не работает сохранение», не открыв ни Network, ни логи. Разработчик тратит время на то, что вы выяснили бы за пять минут.

Путают 500 с 502 и 504. Эти коды чаще говорят о проблеме прокси, недоступном сервисе или таймауте, а не об ошибке в коде обработчика.

Не заглядывают в базу. Бывает, что запись создалась, а упало то, что шло после неё, и повтор запроса плодит дубли.