Как баг в AI-карточках на Авито привел к двойному списанию: разбор инцидента

Недавний инцидент с AI-карточками на платформе Авито стал ярким примером того, как сложные системы могут столкнуться с неожиданными проблемами. Баг, который был выявлен не через стандартный мониторинг, а благодаря жалобе клиента, показал, что в процессе генерации изображений возникли серьезные недочеты, которые требовали немедленного вмешательства.

Проблема, выявленная клиентом

Клиент сообщил, что AI-карточка была успешно сгенерирована и появилась в пикере, однако счётчик кадров в пакете не уменьшился. Это означало, что генерация не была учтена, и клиент не потерял кадр, хотя фактически генерация произошла. Разбор логов, проведенный 5 сентября, показал, что первая гипотеза о двойном клике на кнопку не подтвердилась: идентификатор генерации оставался единственным.

Архитектура генерации AI-карточек

Генерация фото в сервисе AI-карточек осуществляется через провайдер _KieTaskProvider, который имеет несколько уровней ретраев. Эти уровни были добавлены по мере возникновения инцидентов за последние месяцы, что усложнило архитектуру системы. Для анализа времени генерации были взяты константы из файлов providers.py и service.py. Расчеты показали, что:

Poll: 2 попытки × _POLL_TIMEOUT_S=150с = 300с

Download: 2 попытки × httpx timeout=60с = 120с

Итог: одна успешная генерация занимает примерно 420 секунд.

С учетом дополнительных этапов, таких как QA-проверка и запись файла, общее время генерации достигло 960 секунд (или 16 минут). Однако значения SWEEP_AFTER_MIN и QUOTA_RESERVE_TTL_MIN у воркера были установлены на 15 минут, что создало потенциальный конфликт.

Конфликт между уборщиком и генерацией

Уборщик (worker) выполняет периодическую задачу, которая ищет строки резерва старше установленного времени и считает их брошенными. Если клиент не дождался завершения генерации, кадр возвращается в пакет. Однако проблема заключалась в том, что "брошенный" и "долго идущий" резервы не отличались по времени, если окно резерва было меньше реального худшего случая. Таким образом, уборщик мог удалить строку резерва, которая все еще находилась в процессе генерации, и вернуть кадр в счётчик пакета. В результате, когда провайдер успешно завершал генерацию, сервис вызывал release_claim, который не находил строку, так как она уже была удалена уборщиком. Это приводило к тому, что клиент получал и картинку в пикере, и кадр обратно в лимите пакета, но списание не происходило.

Решение проблемы

Первоначально было предложено просто увеличить оба тайм-аута до 20 минут, но это решение не учитывало возможные изменения в логике QA. Вместо этого были предприняты два ключевых шага: 1. Увеличили значения SWEEP_AFTER_MIN и QUOTA_RESERVE_TTL_MIN до 30 минут, что обеспечивало почти двукратный запас по сравнению с расчетным временем генерации. 2. Добавили новый тест, который вычисляет худший случай на основе текущих констант, что позволяет избежать проблем в будущем при изменении логики. Таким образом, если кто-то в будущем добавит дополнительные проходы QA или изменит таймауты, тест автоматически пересчитает свои пороги и упадет, если окно уборщика не будет увеличено.

Второй баг в коде

Во время анализа был обнаружен еще один, независимый баг, связанный с флагом ai_dislike_retry_used. Этот флаг устанавливался при нажатии клиентом кнопки "не нравится" на сгенерированной карточке и не сбрасывался, если процесс API падал между захватом повторной генерации и вызовом release_claim. Это приводило к тому, что клиент терял возможность воспользоваться бесплатным повтором без уведомления.

Заключение

В результате проведенной работы были исправлены как первый, так и второй баги, что позволило улучшить стабильность и надежность системы генерации AI-карточек на Авито. Важно отметить, что тщательный анализ логов и проверка соседних участков кода могут помочь в выявлении скрытых проблем, что подтверждает необходимость комплексного подхода к тестированию и мониторингу систем.