Примеры исключений, когда 400 или 500 ошибки не соответствуют клиенту или серверу
Что проверяют
Не читаете ли вы код ответа буквально: 4xx это вина клиента, 5xx это вина сервера. Хороший тестировщик знает, что код ставит тот, кто отвечает, и ошибиться в нём можно в обе стороны.
Как отвечать
Разберите случаи, где код не совпадает с виновником.
- Сервер не проверил входные данные и упал внутри, отдав 500 на заведомо кривой запрос. Виноват сервер, и починка двойная: валидация плюс корректный 400 в ответе.
- Ответ пришёл не от приложения, а от прокси или балансировщика. Слишком длинные заголовки и куки дают 400 ещё до того, как запрос дошёл до кода, а 502 и 504 означают, что приложение запроса вовсе не видело.
- Отказала внешняя система, база или платёжный шлюз, и приложение честно вернуло 500, хотя собственный его код исправен.
- Код успешный, а ошибка в теле. GraphQL отдаёт ошибки внутри ответа с кодом 200, так же устроены многие самодельные обёртки над старыми сервисами.
- Ограничение по частоте запросов прилетает клиенту, который ничего не нарушал, потому что лимит считается на общий адрес за сетевым шлюзом.
Расскажите, как разбираетесь: смотрите тело ответа и заголовки, ищете идентификатор запроса, сверяетесь с логами и трассировкой, повторяете запрос напрямую, мимо интерфейса.
Где спотыкаются
Заводят дефект по одному коду, не открыв тело ответа. Страница на HTML вместо описанного в контракте JSON сразу говорит, что отвечало не приложение, и адресат у задачи другой.
Второе: не заводят дефект на 4xx вовсе, считая, что клиент сам виноват. Если валидный по документации запрос получает 400, сломан контракт или документация, и это дефект.
Третье: принимают за ошибку сервера то, что заблокировал сам браузер. Отказ по политике доступа между источниками выглядит как сетевой сбой, своего кода ответа у него нет, и причину ищут в заголовках, а не в логике сервиса.