new_lottery_bot/docs/OPERATOR_SCENARIO_AUDIT.md

Проверка операций со счетами и сценариев бота — 14 сентября 2026

Что подтвердилось на сервере

Проверен контейнер lottery_bot, исходная версия f3f8d0f, деплой №93. Контейнер работал, healthcheck проходил, автоматических перезапусков не было. При этом отдельные действия завершались исключениями: состояние контейнера само по себе не проверяет функциональность меню.

В логах за сутки найдены DetachedInstanceError при добавлении счетов и ValueError при выборе «Участники по розыгрышам». Проверка базы во время диагностики показала отсутствие записей счетов и участий с номерами счетов. Поэтому проверены обе причины пропуска: новый счёт с известной картой и повтор уже добавленного счёта. Точный исходный текст клиента в предоставленных логах отсутствует.

Исправления

• При отклонённой операции rollback() инвалидировал загруженные ORM-объекты. Итоговый ответ обращался к lottery.title после закрытия сессии. Теперь необходимые значения сохраняются до операции; аналогичные обращения исправлены в одиночных и массовых операциях по пользователям.
• Быстрый ввод КАРТА СЧЁТ не создавал отсутствующий счёт, хотя предварительный экран находил владельца карты. Теперь известная карта позволяет создать счёт и участие одной транзакцией. Уникальность счёта защищает работу кассиров в разных розыгрышах; владелец существующего счёта не меняется.
• Широкие фильтры кнопок перехватывали отчёты, подтверждения переигровки и удаления, редактирование победителя. Фильтры теперь проверяют полный формат и допустимый числовой ID. Нераспознанная кнопка получает понятный ответ.
• PostgreSQL-прогон выявил несовместимость SELECT DISTINCT по розыгрышам с JSON-полями. Меню редактирования и удаления победителей используют EXISTS: розыгрыш выводится один раз без сравнения JSON.
• Удалённые розыгрыши и истёкшие данные диалога обрабатываются без NoneType и IndexError.
• Добавление и удаление счёта из детального меню используют общие транзакционные проверки открытого розыгрыша и владельца.
• Экраны победителей поддерживают участие без Telegram-профиля. При ручном назначении по счёту сохраняется именно выбранный билет; один счёт нельзя назначить на разные призовые места.
• Имена, названия с символами HTML и длинные списки не ломают ответы в проверенных операциях со счетами. Длинные отчёты разделяются, кнопки остаются на последней странице. Завершённый диалог очищается до отправки итогового отчёта.

Как воспроизводятся сценарии

tests/test_operator_scenarios.py отправляет сообщения и нажатия через настоящий main.dp.feed_update. Используются отдельная база и синтетические Telegram ID. Вместо сети транспорт сохраняет вызовы API и проверяет длину текста, структуру HTML и callback-data. Ошибки, перехваченные middleware, также приводят к падению теста.

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

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

В Drone тесты выполняются на SQLite и отдельно на PostgreSQL 16 с Redis 7. Для PostgreSQL-прогона TEST_REDIS_URL включает настоящий Redis FSM и блокировки диалогов. Тестовая очистка ограничена пространством синтетического бота fsm:123456:*.

Эмуляция не создаёт настоящих розыгрышей и не отправляет сообщения клиентам. Она не заменяет проверку интерфейса приложением Telegram. После CI требуется отдельно проверить установленную версию, healthcheck, heartbeat, Telegram API и новые ошибки контейнера.