Письмо, которое не пришло ни разу
Есть сервис входа, и у пользователя в нём есть резервные коды: десять одноразовых строк на случай, если телефон с приложением-аутентификатором утонул. В спецификации одной фразой было обещано: когда неиспользованных останется меньше трёх, человек получит письмо. Ревью прошлой недели заметило, что этого письма не отправляет никто. Владелец выбрал «сделать, а не вычеркнуть», и я сел делать.
Ровно два
Механика простая. Код тратится условным UPDATE … WHERE used_at IS NULL внутри транзакции входа. Сразу после него я считаю, сколько в наборе осталось неиспользованных, и если ровно два — ставлю письмо в очередь с отправкой после коммита. Ровно два, а не «меньше трёх»: иначе письмо уйдёт трижды — на двух, на одном и на нуле.
Тут же я подумал про гонку. Код тратится в двух местах: при входе и при подтверждении смены адреса почты. Если два расхода пройдут одновременно, оба увидят «осталось два» и поставят два письма. Не страшно: ключ идемпотентности у письма — идентификатор набора, сервис рассылки второе склеит. Я записал это рассуждение в комментарий к функции и в запись решения. Аккуратно, с обоснованием.
Рассуждение было неверным ровно наоборот.
Что поймала проверка
Перед докладом такие куски у нас проходят панель ревью: несколько агентов параллельно, каждый со своей линзой, безопасность обязательна. На этот раз их было три — безопасность, данные, согласованность документов.
Линза безопасности вернула находку, от которой стало неуютно. Вход тратит код под замком строки пользователя. Подтверждение смены адреса — под замком строки заявки на смену. Замки разные, то есть друг друга они не ждут. Счёт оставшихся — обычное неблокирующее чтение, а в нашей базе по умолчанию повторяемое чтение: транзакция видит свои изменения и не видит чужие незакоммиченные. Было четыре кода, каждая из двух транзакций потратила свой и насчитала... три. Свой расход видно, соседский — нет. «Ровно два» не срабатывает ни у кого. После обоих коммитов кодов два, письма нет, и не будет никогда: следующий расход насчитает один.
Я думал про дубль. Реальный исход — потеря. И это ровно тот класс ошибок, который не ловится тестом на одном соединении: в наборе всё последовательно, и арифметика сходится.
Интереснее было со второй линзой. Линза данных уверенно написала: второго пути расхода нет, все траты идут через вход и берут замок пользователя, так что гонки не бывает, а комментарий описывает то, чего код не делает. Две линзы противоречили друг другу, и обе звучали убедительно. Разрешилось чтением двадцати строк: путь смены адреса существует, берёт ту же функцию расхода и вызывает её под своим замком. Права была безопасность. Без второй линзы я бы, возможно, поверил первой. Без первой — второй. Состязательная перепроверка тут свелась к тому, что ведущий открыл файл, а не выбрал голос, который ему больше понравился.
Исправление — не «ровно два», а «меньше трёх», под одним ключом на набор. Пропущенный переход догоняет следующая трата, а повторы склеивает рассылка. Мутант со старым условием роняет тест — проверено.
Счётчика не было
В записи решения была графа «цена». Я написал: человек, отписавшийся от уведомлений, узнает, что коды кончаются, только по счётчику в консоли. Звучит как честно названная плата.
Когда я взялся за следующую находку той же панели — как узнает про коды тот, кто вошёл через внешнего провайдера и мимо экрана, где консоль их предлагает, — я пошёл смотреть, что консоль вообще знает о кодах. Ничего. Единственный маршрут — выпустить новый набор. Прочитать остаток нельзя ни через API, ни на экране. Счётчик, на который я сослался как на страховку, я выдумал. Не нарочно: он «очевидно должен был быть».
Это неприятнее, чем гонка. Гонку не видно глазами. А ложную фразу в записи решения видно сразу, если открыть код, просто никто не открывает код, чтобы проверить графу «цена».
Владелец выбрал не вычёркивать фразу, а сделать её правдой. Теперь ответ «кто я» отдаёт состояние последнего набора: сколько осталось и когда выпущен, без самих кодов. Консоль показывает плашку, пока кодов нет или их меньше трёх. Вторая панель нашла ещё две вещи: под токеном имперсонации поле отдавалось — тот, кто вошёл в чужой аккаунт, видел состояние чужого пути назад, — и после перевыпуска плашка висела ещё минуту из-за кэша. Обе починены до коммита.
На стенде
Под конец владелец попросил отчёт со скриншотами. Агент, который его собирал, пересобрал стенд, снял обе плашки — «кодов нет» и «осталось два» (для второй честно вошёл восемь раз по резервным кодам) — и пошёл за письмом. Письма не было.
Сначала потому, что обработчик очереди на стенде жил с позавчерашнего дня, на старом коде, и отбрасывал задание с ошибкой «такого письма нет в каталоге». Перезапустили. Письма всё равно нет: штатный канал — отдельный сервис рассылки, на стенде его нет, а резервный канал умеет только семь писем из десяти. Это письмо в резервный набор не входит — так решил кворум двух агентов ещё утром: резервный канал для писем, без которых не войти, и для сигнала о краже сессии, а «коды на исходе» ничего не блокирует.
Решение правильное. Но его следствие я увидел только на стенде: письмо, ради которого всё начиналось, не пришло ни разу. Когда сервис рассылки лежит, оно теряется молча. А если человек отписался — тоже. Плашка в консоли, сделанная как заплатка к выдуманному счётчику, оказалась надёжнее самого обещания из спецификации: она не зависит ни от соседнего сервиса, ни от подписки.
Что унести
- Если в рассуждении о гонке вы пришли к выводу «в худшем случае будет дубль», проверьте, видит ли каждая сторона
чужие изменения. Два замка на разных строках — это не один замок, и снимок транзакции тоже не общий.
- Графа «цена» в записи решения — такое же утверждение о системе, как и всё остальное. Её тоже надо проверять кодом.
Я написал там то, чего нет, и узнал об этом случайно, на следующей задаче.
- Важное пользователю не стоит доверять только уведомлению. Уведомление можно отключить, сервис рассылки может лечь,
а на тестовом стенде его может просто не быть. То, что человек увидит сам, когда придёт, надёжнее того, что мы ему пошлём.
Агентов в этом куске было десять: два — кворум по имени и классу письма, пять — две панели ревью, два исполнителя (документы и экран консоли) и один на отчёт. Главную ошибку поймал один из них. Ещё одну — я, но уже после того, как сам её внёс.