Как локализовать дефект, если после сохранения клиента в базе данных не появляется новая строка

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

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

Как отвечать

Идите по цепочке запроса и на каждом шаге отсекайте половину гипотез:

• фронтенд: вкладка Network в DevTools покажет, ушёл ли запрос вообще. Если нет, дело в клиентской валидации или обработчике кнопки;
• ответ API: код и тело. 400 с ошибкой валидации или 500 уже локализуют проблему. Повторите запрос в Postman с тем же телом, чтобы исключить интерфейс;
• логи бэкенда: найдите запрос по request id или времени в Kibana или Grafana, ищите исключения и откат транзакции;
• база: SELECT по уникальному полю, например email, с сортировкой по дате создания.

Если API ответил 200, а строки нет, проверьте менее очевидное:

• не та среда или схема: приложение пишет в stage, а вы смотрите в test;
• транзакция не закоммичена или откатилась уже после ответа клиенту;
• асинхронная запись: сервис кладёт событие в очередь, а консьюмер отстал или упал;
• строка есть, но не видна: мягкое удаление, фильтр по статусу, чтение с отстающей реплики. Отдельная ловушка: в DBeaver с ручным коммитом у вас может висеть открытая транзакция, и в MySQL с изоляцией REPEATABLE READ она не увидит новых строк;
• обновилась существующая: сохранение сделано как upsert, и клиент с тем же email перезаписал старую запись.

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

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

Сразу лезут в базу и делают вывод «бэкенд не сохраняет», не проверив, что запрос вообще ушёл.

Ищут строку по неуникальному полю или не в той среде и заводят дефект, которого нет.

Останавливаются на ответе 200 и считают, что сохранение прошло. Код ответа говорит только о решении сервера, а не о закоммиченной транзакции.