Что делать при ошибке 500 без описания при нажатии кнопки войти
Что проверяют
Умеете ли вы из «ничего не работает» собрать дефект, с которым разработчик начнёт не с нуля. Смотрят, дойдёте ли вы до самого запроса и ответа, отличите ли ошибку приложения от инфраструктурной и верно ли оцените срочность.
Как отвечать
Сначала открыть сетевую вкладку инструментов разработчика: адрес и метод запроса, тело, код и тело ответа, заголовки. Там же ищется идентификатор запроса или трассировки, по нему разработчик идёт сразу к нужной записи в логах, а не перебирает всё за минуту времени.
Дальше отделить слои. Настоящий код 500 приходит от приложения, а 502 и 504 обычно означают, что до сервиса не дошли или он не ответил вовремя, и это уже инфраструктура. Полезно проверить соседние запросы: если регистрация и восстановление пароля тоже падают, дело в общей зависимости вроде базы или сервиса авторизации.
Затем сузить условия:
- всегда или иногда, сколько раз из десяти попыток;
- на всех учётных записях или только на конкретной, влияют ли данные вроде длинного пароля и нелатинских символов;
- на всех стендах или на одном, появилось ли после выкладки и какой именно;
- на чистой сессии, в другом браузере, из другой сети.
В дефект идут запрос и ответ целиком, точное время с часовым поясом, идентификатор трассировки, стенд и версия сборки, учётная запись, частота. Вход это блокер, поэтому сообщать надо сразу, не дожидаясь конца прогона.
Где спотыкаются
Пишут «не работает вход» и прикладывают скриншот пустого экрана. Без запроса, времени и стенда поиск в логах превращается в перебор, и дефект возвращается за уточнениями.
Второе: считают, что 500 это всегда вина бэкенда. Если клиент отправил заведомо неверное тело, дефектов два: клиент шлёт мусор, и сервер отвечает пятисоткой вместо внятной ошибки валидации.
Третье: не замечают второй дефект прямо в наблюдаемой картине. Пользователь получил ошибку без объяснения и без возможности повторить попытку, и это отдельная задача про поведение интерфейса при отказе.