Что происходит с сохранением данных при исключении в методах save в базе данных

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

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

Как отвечать

Ожидаемое поведение простое: если сохранение идёт в одной транзакции и в середине летит исключение, не должно остаться ничего, в том числе частично. Проверка при этом всегда идёт запросом в базу, а не по списку в интерфейсе: список может читаться из кэша или с отстающей реплики.

Что стоит включить в сценарии:

• нарушение ограничения: дубль по уникальному полю, пустое обязательное значение, ссылка на несуществующую запись;
• обрыв в середине: сохранение нескольких связанных сущностей, ошибка на второй;
• отказ соединения с базой во время операции, а не до её начала;
• одновременная запись из двух сессий в одну и ту же строку;
• повтор той же операции после ошибки, не появится ли дубль.

Отдельный слой проверок это побочные эффекты за пределами базы: письмо, сообщение в брокер, файл в хранилище, вызов внешнего платёжного сервиса. Откат транзакции их не отменяет, и самый частый настоящий дефект живёт именно здесь.

Ещё проверьте, что наружу отдаётся честный код ошибки, а не успешный ответ с пустым телом, и что в сообщении нет трассировки стека.

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

Смотрят только интерфейс. Записи не видно, значит не сохранилось. На деле запись может быть, просто список кэширован или отфильтрован, и дефект уезжает на продакшен.

Берут одну ошибку из целого класса. Дубль по уникальному индексу ловят, а обрыв соединения в середине нет, хотя именно на нём всплывают недописанные наборы связанных записей.

Заводят дефект на пропуски в идентификаторах. Последовательность вместе с транзакцией не откатывается, пропуски после неудачной вставки нормальны, и спорить тут стоит не с базой, а с требованием непрерывной нумерации, если оно вообще где-то записано.