Как локализовать баг при неожиданном изменении номера заявки
Что проверяют
Умеете ли вы сужать область поиска, а не отдавать баг разработчику со словами «номер поменялся». Интервьюер ждёт, что вы пройдёте по цепочке от экрана до базы и найдёте место, где значение становится неправильным. Следом спрашивают, что попадёт в баг-репорт.
Как отвечать
Сначала уточните симптом, от него зависит, где искать: у существующей заявки номер сменился после какого-то действия, новая получила номер с пропуском или дубль чужого, либо номер разный на разных экранах и в письме.
Дальше идите по слоям и на каждом сравнивайте значение:
- интерфейс: какой номер показан и откуда он берётся. Иногда на экране выводится порядковый номер строки в списке, а не идентификатор;
- API: в DevTools на вкладке Network посмотрите ответ сервера. Если API отдаёт правильный номер, а экран показывает другой, проблема на фронте: маппинг полей, кэш, состояние;
- база: запрос по заявке, поля аудита вроде
updated_at, таблица истории, триггеры. Если номер в базе уже другой, ищите, кто его перезаписал; - логи: по идентификатору запроса или trace id найдите цепочку вызовов, фоновые задачи, синхронизацию с внешней системой, импорт.
Сверьте время: совпадает ли начало проблемы с релизом, миграцией или ночным заданием. Попробуйте конкурентный сценарий: два запроса на создание одновременно, двойной клик по кнопке, нагрузка через JMeter или k6. Генерация номера по схеме «максимальный плюс один» даёт дубли именно под конкуренцией.
В баг-репорт идут шаги, окружение, номер до и после, запрос и ответ API, trace id и вывод, на каком слое значение портится.
Где спотыкаются
Считают багом любой пропуск в нумерации. Последовательности в PostgreSQL не откатываются вместе с транзакцией, поэтому дыры после отменённых вставок это нормальное поведение, если требования не обещают сплошную нумерацию.
Проверяют только интерфейс и не смотрят в Network и базу, хотя сравнение значения по слоям и есть локализация.
Воспроизводят сценарий одним пользователем в одной вкладке и не пробуют параллельные запросы, а такие баги обычно живут именно там.