Stabilize staff concurrency and premium emoji; enable verified Drone deployment
Some checks failed
continuous-integration/drone/push Build is failing

This commit is contained in:
2026-09-13 19:48:41 +09:00
parent 733298bf06
commit cb35bb12e3
86 changed files with 2993 additions and 2455 deletions

75
docs/DRONE_DEPLOYMENT.md Normal file
View File

@@ -0,0 +1,75 @@
# Автодеплой через Drone
Drone: `https://drone.smartsoltech.kr`, цель: `trevor@192.168.40.112:/opt/new_lottery_bot`, репозиторий `trevor/new_lottery_bot`, production-ветка `master`.
Подготовленный pipeline запускает деплой только для успешного `push` в `master` после проверок, PostgreSQL-тестов и сборки архива. Pull request запускает проверки без передачи deployment-секретов.
## Секреты репозитория
| Имя в Drone | Значение |
| --- | --- |
| `lottery_deploy_user` | SSH-пользователь сервера с доступом к Docker и каталогу приложения |
| `lottery_deploy_path` | Отдельный абсолютный каталог, например `/opt/new_lottery_bot` |
| `lottery_deploy_ssh_key` | Закрытый SSH-ключ этого пользователя, пригодный для неинтерактивного входа |
| `lottery_deploy_known_hosts` | Проверенная запись ключа сервера для `192.168.40.112` |
| `lottery_env` | Полный актуальный production env-файл с BOT_TOKEN, DATABASE_URL, ADMIN_IDS и остальными настройками |
Настройка использует [официальный API создания](https://docs.drone.io/api/secrets/secret_create/) и [обновления секретов](https://docs.drone.io/api/secrets/secret_update/). Скрипт передаёт `pull_request=false`, повторно проверяет наличие имён и не печатает значения. Учётной записи нужны права записи в репозиторий.
На Windows, из корня проекта, после заполнения файлов за пределами репозитория:
```powershell
.\.venv\Scripts\python.exe scripts/configure_drone_secrets.py `
--server https://drone.smartsoltech.kr `
--repo trevor/new_lottery_bot `
--token-file C:\secure\drone-token.txt `
--ssh-key C:\secure\lottery-deploy-key `
--known-hosts C:\secure\lottery-known-hosts `
--env-file C:\secure\lottery-production.env `
--deploy-user trevor `
--deploy-path /opt/new_lottery_bot
```
Пути `C:\secure\...` — примеры файлов с ограниченными правами доступа. Токены не нужно вставлять в командную строку. Отпечаток host key сверяется через доверенный доступ к серверу; автоматическое принятие неизвестного ключа отключено. Для Drone используется отдельный ключ `id_ed25519_lottery_deploy`; пользователь `trevor` имеет доступ к Docker и каталогу приложения.
При подготовке deployment актуальные настройки взяты из работающего контейнера: PostgreSQL 16 расположен на `192.168.20.2`, база `lottery_bot`. Локальный старый `.env.prod` не является источником production-настроек. Проверено совпадение эффективных BOT_TOKEN, DATABASE_URL, REDIS_URL, ADMIN_IDS и имён volumes с действующим Compose-проектом `new_lottery_bot`. Все пять секретов созданы в Drone с запретом передачи pull request.
Резервная копия рабочей БД восстановлена в изолированном PostgreSQL 16; обновление с `20260701_perf_indexes` до `20260913_staff_concurrency` и проверка схемы прошли. При обновлении PostgreSQL согласованно обновлять клиент резервного копирования: [PostgreSQL не гарантирует восстановление дампа нового клиента в более старую major-версию сервера](https://www.postgresql.org/docs/17/app-pgdump.html#APP-PGDUMP-NOTES).
## Перед первым деплоем
1. Активировать репозиторий в Drone. Runner должен получать Git-репозиторий и обращаться по SSH к `192.168.40.112`; сервер должен иметь доступ к registry/PyPI для сборки.
2. На сервере нужны Docker Engine, Compose v2 с поддержкой `--wait`, `flock`, `tar`, `install`. Пользователь должен иметь доступ к Docker и выделенному каталогу. Подготовить ключ и проверить обычный неинтерактивный SSH-вход.
3. Если уже существует контейнер `lottery_bot`, проверить его label `com.docker.compose.project`. Скрипт ожидает `new_lottery_bot` и остановится при другом проекте, чтобы не подменить чужой стек. Существующие volumes, каталог и внешний PostgreSQL необходимо сопоставить до переноса. Не запускать `down -v`.
4. В `.env.prod` использовать реальные настройки из `.env.prod.example`. Для внешней БД оставить `COMPOSE_PROFILES` пустым и указать доступный из контейнера PostgreSQL в `DATABASE_URL`; POSTGRES_PASSWORD не требуется. Для БД в этом Compose задать `COMPOSE_PROFILES=local-db`, непустой POSTGRES_PASSWORD, согласованные POSTGRES_* и адрес `postgres` в URL. Спецсимволы пароля внутри URL должны быть URL-encoded. Клиент резервного копирования и PostgreSQL в Compose/CI используют major-версию 16, соответствующую рабочей БД.
5. При использовании переменных со знаком `$` учитывать интерполяцию Compose env-файла; заключать соответствующее значение в одинарные кавычки. Проверять конфигурацию командой `docker compose --project-name new_lottery_bot --env-file .env.prod config --quiet`, чтобы значения секретов не попадали в вывод.
6. Проверить доступ к целевой БД и возможность `pg_dump`. БД должна уже существовать. Пользователю миграций нужны права изменения принадлежащих приложению объектов. Исторические дубликаты миграция сообщает без удаления данных.
7. Загрузить пять секретов указанным скриптом, опубликовать изменения в `master` и дождаться завершения **всего** pipeline, включая `deploy`.
## Последовательность deployment-скрипта
- Получает архив и env-файл по SSH с обязательной проверкой host key.
- Берёт файловую блокировку деплоя и отклоняет устаревший номер сборки.
- Создаёт каталог `releases/COMMIT-BUILD`, собирает образ с тегом commit и поднимает Redis/необходимую локальную БД.
- Делает PostgreSQL backup в `backups/COMMIT-BUILD-UTC_TIMESTAMP.dump` с ограниченными правами. Дальнейшие действия прекращаются, если backup не получен.
- Останавливает старого polling-бота, выполняет `alembic upgrade head` и проверку схемы.
- Запускает новый образ, ожидает healthcheck, проверяет heartbeat приложения и только затем переключает `current` и записывает `last-build`.
- При ошибке после остановки пытается вернуть прежний образ. **Это откат приложения:** схема БД автоматически не откатывается; используется env текущего deployment. Восстановление БД из backup требует отдельного решения. При первом запуске предыдущего образа может не быть.
Heartbeat обновляется после проверки БД в работающем event loop; до запуска бот проверяет Redis, схему и Telegram `getMe`. Сбой heartbeat останавливает приложение, после чего действует Docker restart policy. Один только Docker healthcheck не является проверкой каждого бизнес-сценария или факта доставки всех сообщений.
## Проверка результата
После успешного шага `deploy` проверить `/start`, админку, `/cashier` со второго Telegram-аккаунта, добавление участника и тестовый розыгрыш. В логах должны отсутствовать ошибки миграций, `Conflict: terminated by other getUpdates request` и повторяющиеся ошибки соединения с БД. Проверить сохранение FSM после штатного рестарта, содержимое backup и возможность восстановления на отдельной тестовой БД.
Локальные команды CI:
```powershell
.\.venv\Scripts\python.exe -m pip install -r requirements-dev.txt
.\.venv\Scripts\python.exe -m ruff check src main.py scripts tests migrations
.\.venv\Scripts\python.exe -m pytest -q
.\.venv\Scripts\python.exe -m pip_audit -r requirements.txt
.\.venv\Scripts\python.exe scripts/check_secrets.py
.\.venv\Scripts\python.exe scripts/build_release.py
```
Для PostgreSQL-тестов задаётся `TEST_DATABASE_URL` **только отдельной одноразовой тестовой БД**: тесты удаляют и создают в ней таблицы. Пользователю тестов также требуется `CREATEDB` для проверки миграций. Рабочий `DATABASE_URL` тестами не используется: `tests/conftest.py` подставляет временную SQLite БД, если `TEST_DATABASE_URL` не указан.

View File

@@ -1,244 +1,52 @@
# Система управления кастомными эмодзи
# Премиум-эмодзи в чате и рассылках
## Обзор
Поддержка добавлена для общего чата, личных диалогов, рассылок в личные сообщения, каналы и группы. Сохраняются ID выбранных премиум-эмодзи, оформление текста и подписи к медиа. Новые миграции и переменные окружения для этой функции не требуются.
Система позволяет администраторам регистрировать премиум эмодзи и использовать их в сообщениях бота. Когда админ отправляет эмодзи боту:
## Использование
1. Бот получает `emoji_id` от Telegram API
2. Сохраняет эмодзи в таблице `emoji_mappings`
3. При отправке сообщений в чаты бот автоматически использует `emoji_id` вместо текста эмодзи
1. Выберите премиум-эмодзи в панели Telegram и отправьте сообщение в режиме чата либо создания рассылки.
2. Для подписи к фото, видео или документу добавьте эмодзи прямо в подпись.
3. Бот сохраняет выбранный вариант эмодзи, включая случаи, когда у нескольких премиум-вариантов одинаковый обычный символ.
Это обеспечивает, что эмодзи будут выглядеть точно так же, как их отправил админ, даже если это премиум эмодзи.
Имя отправителя добавляется с сохранением оформления сообщения. Если заголовок не помещается вместе с текстом или подписью в лимит Telegram, бот отправляет заголовок отдельно и копирует исходное сообщение целиком.
## Команды администратора
Условия Telegram: новые сообщения с custom emoji могут отправлять боты с дополнительным именем пользователя, приобретённым через Fragment. Также они разрешены в сообщениях бота в личных чатах, группах и супергруппах, если **владелец бота** имеет активную подписку Telegram Premium. Исключение по подписке владельца в документации не распространяется на каналы. Эти условия задаёт Telegram; флаг внутри приложения их не меняет. [Официальная документация](https://core.telegram.org/bots/api#formatting-options).
### 1. Добавить новый эмодзи
Отправка обычного Unicode-символа передаёт обычный эмодзи. Премиум-вариант определяется полем `custom_emoji_id`, которое Telegram присылает вместе с выбранным эмодзи. Предварительная регистрация в каталоге для чата и рассылки не требуется.
```
/add_emoji
```
## Каталог администратора
Процесс:
1. Админ запускает команду `/add_emoji`
2. Бот просит отправить эмодзи
3. Админ отправляет эмодзи (например, 🎲)
4. Бот просит описание (для чего используется)
5. Админ отправляет描述 (например, "Для лотереи")
6. Бот сохраняет в БД и подтверждает
- `/add_emoji` — сохранить один премиум-эмодзи и описание для шаблонов.
- `/my_emojis` — показать свои записи.
- `/all_emojis` — показать общий каталог.
- `/delete_emoji` — удалить свою запись. Главный администратор также может удалять записи других сотрудников.
### 2. Просмотр своих эмодзи
Команда добавления принимает настоящий `custom_emoji` из Telegram. Описание ограничено 255 символами. Связь записи с администратором хранится через внутренний ID пользователя в БД; интерфейс принимает Telegram ID. Повторная регистрация даёт понятный ответ без повреждения сессии БД.
```
/my_emojis
```
## Реализация
Показывает все эмодзи, добавленные этим админом:
- Сам эмодзи
- Описание
- ID (первые 30 символов)
- Дату добавления
`src/utils/telegram_messages.py` содержит общий путь передачи сообщений:
### 3. Просмотр всех эмодзи в системе
- без заголовка используется `copyMessage`, сохраняющий исходное сообщение;
- при добавлении имени передаются исходные `entities` / `caption_entities` с поправкой позиции на длину заголовка в UTF-16;
- `parse_mode=None` предотвращает повторный разбор пользовательского текста;
- длинные сообщения копируются без обрезания текста или разрыва эмодзи.
```
/all_emojis
```
Общий чат, P2P и оба вида рассылок используют этот путь. Ошибка оформления сообщения, включая недопустимый custom emoji, учитывается как ошибка доставки и не блокирует получателя для следующих рассылок.
Показывает все эмодзи всех админов с информацией об администраторе
### 4. Удалить эмодзи
```
/delete_emoji
```
Админ может удалить только свои эмодзи. Процесс:
1. Вызвать команду
2. Выбрать эмодзи из список (кнопки)
3. Бот удалит из БД
## Использование в коде
### Простой способ - прямое использование эмодзи
Для программно создаваемого шаблона из обычного текста доступен HTML-рендер каталога:
```python
from aiogram.types import Message
async def handler(message: Message):
await message.answer(
text="🎲 Добро пожаловать на лотерею! 🏆",
parse_mode="HTML"
)
```
### С обработкой эмодзи
```python
from sqlalchemy.ext.asyncio import AsyncSession
from src.core.emoji_message_helper import get_emoji_aware_text
from aiogram.types import Message
async def handler(message: Message, session: AsyncSession):
# Текст с эмодзи
original_text = "🎲 Выиграли! 🏆"
# Обработаны текст (эмодзи заменены на ID для корректного отображения)
processed_text = await get_emoji_aware_text(session, original_text)
await message.answer(processed_text, parse_mode="HTML")
html = await get_emoji_aware_text(session, "🎲 Розыгрыш начался!")
await bot.send_message(chat_id, html, parse_mode="HTML")
```
### Работа с EmojiMessageHelper
Вход этого помощника — обычный текст. Он экранирует HTML и добавляет настоящие `<tg-emoji emoji-id="...">...</tg-emoji>`. Входящие пользовательские сообщения сохраняют собственные entities и не проходят через каталог замен.
```python
from sqlalchemy.ext.asyncio import AsyncSession
from src.core.emoji_message_helper import EmojiMessageHelper
## Проверка
async def handler(message: Message, session: AsyncSession):
helper = EmojiMessageHelper(session)
# Обработка перед отправкой
text = "🎲 Лотерея начинается! 💎"
processed = await helper.process_text_before_send(text)
await message.answer(processed, parse_mode="HTML")
```
`tests/test_premium_emoji.py` проверяет ID и UTF-16-позиции нескольких эмодзи, вложенное оформление, подписи к шести типам медиа, предельную длину текста/подписей, P2P-доставку, копирование рассылок, ошибки Telegram и настоящий маршрут регистрации эмодзи. Ответы Telegram в тестах подменены; права конкретного рабочего бота и отображение в клиенте Telegram нужно проверить после установки релиза.
## Структура БД
### Таблица `emoji_mappings`
| Колонка | Тип | Описание |
|---------|-----|---------|
| `id` | Integer | Primary Key |
| `emoji_text` | String(10) | Сам эмодзи (например, 🎲) |
| `emoji_id` | String(255) | telegram_emoji_id от API (уникален) |
| `admin_id` | Integer | FK на user (администратор) |
| `description` | String(255) | Описание назначения эмодзи |
| `created_at` | DateTime | Дата добавления |
| `last_used_at` | DateTime | Последнее использование |
### Уникальные ограничения
- `emoji_id` — уникален во всей системе
- `(emoji_text, admin_id)` — один админ не может добавить один эмодзи дважды
## API сервиса EmojiMappingService
### Регистрация эмодзи
```python
from sqlalchemy.ext.asyncio import AsyncSession
from src.core.emoji_mapping_service import EmojiMappingService
async with async_session_maker() as session:
service = EmojiMappingService(session)
emoji = await service.register_emoji(
emoji_text="🎲",
emoji_id="telegram_emoji_id_here",
admin_id=12345,
description="Для лотереи"
)
```
### Получение эмодзи
```python
# По тексту
emoji = await service.get_emoji_by_text("🎲")
# По emoji_id
emoji = await service.get_emoji_by_id("telegram_emoji_id")
# Все эмодзи админа
emojis = await service.get_all_emoji_by_admin(admin_id=12345)
# Все эмодзи
all_emojis = await service.get_all_emojis()
```
### Замена эмодзи в тексте
```python
# Текст → с заменой эмодзи на ID
processed = await service.replace_emojis_in_text(
"🎲 Выиграли! 🏆"
)
# Обратно - ID → эмодзи
original = await service.restore_emojis_in_text(processed)
```
### Получить словарь маппинга
```python
# {emoji_text: emoji_id}
mapping = await service.get_emoji_mapping_dict()
# {'🎲': 'telegram_emoji_id_1', '🏆': 'telegram_emoji_id_2', ...}
```
## Примеры использования в разных рутерах
### В регистрации
```python
async def registration_complete(message: Message, session: AsyncSession):
text = "✅ Регистрация завершена! 🎉"
text = await get_emoji_aware_text(session, text)
await message.answer(text, parse_mode="HTML")
```
### В админ-панели
```python
async def lottery_created(callback: CallbackQuery, session: AsyncSession):
text = "🎰 Новый розыгрыш создан! 🏆"
text = await get_emoji_aware_text(session, text)
await callback.message.edit_text(text, parse_mode="HTML")
```
### В чатовой рассылке
```python
async def broadcast_message(message: Message, session: AsyncSession):
text = f"📢 Сообщение от админа: {message.text}\n\n💎 Удачи!"
text = await get_emoji_aware_text(session, text)
for user_id in target_users:
await bot.send_message(user_id, text, parse_mode="HTML")
```
## Важные моменты
1. **Parse Mode**: Всегда используйте `parse_mode="HTML"` при работе с эмодзи
2. **Кеширование ID**: Система не кеширует, каждый раз обращается к БД. Для оптимизации можно добавить кеширование
3. **Лог использования**: `last_used_at` обновляется автоматически при замене в тексте
4. **Удаление**: Удаленный эмодзи больше не будет заменяться в новых сообщениях
5. **Конфликты**: Если два админа добавляют один эмодзи - они сохранятся отдельно (разные admin_id)
## Миграция
Таблица создана миграцией:
```
migrations/versions/20260307_0100_add_emoji_mappings.py
```
Применить миграцию:
```bash
alembic upgrade head
```
## Trouble Shooting
### Эмодзи не отображается корректно
- Проверьте что используете `parse_mode="HTML"`
- Убедитесь что эмодзи зарегистрирован с помощью `/my_emojis`
### Ошибка "Can't parse entities"
- Это означает что есть конфликт форматирования
- Убедитесь что используете HTML теги (`<b>`, `<i>`, и т.д.), а не Markdown (`**`, `__`)
### Эмодзи не заменяется
- Проверьте что был зарегистрирован с помощью `/add_emoji`
- Убедитесь что используете функцию `get_emoji_aware_text()` перед отправкой
Итоговый прогон 13 сентября 2026: PostgreSQL — 61 тест прошёл; SQLite — 60 прошли, один тест миграций пропущен. Ruff, compileall и проверка отслеживаемых секретов прошли. Изменения подготовлены локально; установки этой версии на рабочий сервер в рамках проверки не было.

View File

@@ -0,0 +1,67 @@
# Проверка и стабилизация бота призовых розыгрышей
Дата: 13 сентября 2026. Исходная ревизия: `733298b`, ветка `master`.
Отчёт о проверках перед выпуском. Результат конкретного deployment проверяется по соответствующему pipeline в Drone и состоянию контейнера на сервере.
## Устройство проекта
| Область | Основные файлы | Назначение |
| --- | --- | --- |
| Запуск | `main.py`, `src/core/config.py`, `src/core/database.py` | aiogram polling, FSM, соединения с БД, фоновые задачи |
| Пользовательские сценарии | `src/controllers/`, `src/components/`, `src/handlers/registration_handlers.py` | Меню, регистрация, просмотр розыгрышей и счетов |
| Управление | `src/handlers/admin_panel.py`, `admin_account_handlers.py`, `cashier_handlers.py` | Администраторы, кассиры, участники, счета, результаты |
| Данные и операции | `src/core/models.py`, `services.py`, `registration_services.py`, `src/handlers/account_services.py` | PostgreSQL, участие, проведение розыгрыша, подтверждение выигрыша |
| Общение | `src/core/chat_services.py`, `broadcast_services.py`, `src/handlers/chat_handlers.py`, `p2p_chat.py` | Чат, личные сообщения, рассылки и модерация |
| Развёртывание | `.drone.yml`, `Dockerfile`, `docker-compose.yml`, `scripts/deploy_release.sh` | CI, артефакт, резервная копия, миграции и запуск |
## Исправленные проблемы
| Приоритет | Проблема | Исправление |
| --- | --- | --- |
| Критический | В Git отслеживался `.env.prod`; пароль БД также находился в Compose | Локальный файл сохранён, его удаление из индекса подготовлено; Compose читает настройки окружения, образ и релиз собираются по разрешённому списку файлов. Старые секреты остаются в истории и требуют замены |
| Высокий | Проверки администратора различались; отдельные callback/FSM шаги позволяли обойти проверку меню | Общий источник ролей и middleware проверяют выбранный обработчик; пользовательские callback выделены явно; права назначенного администратора учитываются в админке |
| Высокий | Два администратора могли одновременно провести один розыгрыш, два кассира — подтвердить один приз | Транзакционная блокировка конкретного розыгрыша, уникальные ограничения, условное обновление неподтверждённого выигрыша |
| Высокий | Повторное добавление участника/счёта и одновременное создание пользователя приводили к дублям или IntegrityError | Атомарная вставка/обновление пользователя, блокировки изменений участия, ограничения уникальности, восстановление сессии после ожидаемых конфликтов |
| Высокий | Победителя по Telegram ID мог подтвердить другой пользователь | Проверяется владелец выигрыша; подтверждение до завершения розыгрыша запрещено |
| Высокий | Повторный розыгрыш мог затронуть подтверждённые призы и конфликтовать с подтверждением кассира | Общий сервис повторного розыгрыша блокирует результаты, заменяет только подходящие неподтверждённые места и сохраняет остальные призы |
| Высокий | Глобальная проверка повторов сообщений путала одинаковые номера из разных чатов; модерация искала сообщение без чата | Ключ `(chat_id, message_id)`; поиск оригиналов и пересланных копий учитывает чат получателя и отклоняет неоднозначный результат |
| Высокий | Синхронный Excel и удержание соединений БД во время массовых отправок мешали другим операциям | Работа с Excel вынесена в поток; данные подготавливаются до отправки; основные рассылки освобождают соединение БД, имеют общий лимит параллельных запросов и темпа |
| Высокий | Первоначальная цепочка Alembic имела две вершины и повторно создавала существовавшие таблицы; рабочая ревизия отсутствовала в Git | Включена фактическая ревизия `20260701_perf_indexes` с сервера и объединяющая миграция; дублирующая историческая ревизия оставлена как пустой переход. Проверяется полная цепочка и обновление с рабочей ревизии |
| Средний | Возврат через кнопку использовал автора сообщения — самого бота | Для действий пользователя передаётся `callback.from_user`; выход очищает его FSM |
| Средний | Excel мог содержать формулы, чрезмерно большой архив или строку, срывающую весь импорт | Экспорт строк как текста; ограничения размера/числа строк; безопасный XML; отдельная транзакция для каждой строки; импорт не назначает административные роли |
| Средний | HTML в имени/тексте ломал пересылку, длинный текст переставал помещаться с заголовком | Экранирование и сохранение Telegram entities; для предельного размера заголовок отправляется отдельно |
| Средний | Разные интерфейсы бана/разбана расходились; повторная запись о блокировке ломала рассылку и задачу неактивности | Оба механизма блокировки согласованы; служебные записи обновляются атомарно |
| Средний | Ошибки SQL/исключений уходили пользователю; были обращения к удалённому `User.account_number` и несуществующим методам | Общие сообщения об ошибке без технических деталей, исправленные обращения к Account и сервисам, критическая статическая проверка в CI |
| Средний | CI скрывал ошибки, а наличие процесса считалось успешным деплоем | Проверки останавливают pipeline при ошибке; проверяются миграции, схема, доступ к БД, запуск Telegram и heartbeat приложения |
| Средний | Установленные зависимости содержали известные уязвимости; старый aioredis несовместим с Python 3.12 | Обновлены aiogram/aiohttp/python-dotenv, удалён неиспользуемый aioredis; выполнен pip-audit |
## Одновременная работа сотрудников
Состояние диалога разделено по боту, чату и пользователю. В Compose используется Redis с сохранением данных; локальный запуск без `REDIS_URL` использует память. Блокировка FSM упорядочивает события одного пользователя, не закрывая доступ другим пользователям. Изменения одного розыгрыша сериализуются на уровне PostgreSQL; разные розыгрыши могут обрабатываться одновременно.
`ADMIN_IDS` задаёт главных администраторов. Назначенные в БД администраторы используют админку. `CASHIER_IDS` либо `User.is_cashier` дают доступ к кассе: счета, добавление участников по счетам и подтверждение выигрышей. Создание/проведение розыгрышей и управление сотрудниками остаются административными операциями.
Главный администратор может выполнить `/add_cashier TELEGRAM_ID`, `/remove_cashier TELEGRAM_ID`, `/cashiers`. Сначала сотрудник должен открыть бота через `/start`. Кассир открывает `/cashier`; `/cancel` отменяет текущий ввод. Для кассира из `CASHIER_IDS` отзыв выполняется через настройку окружения.
Поддерживается один процесс Telegram polling с несколькими одновременно работающими сотрудниками. Запуск нескольких polling-контейнеров с одним токеном не является способом масштабирования этой конфигурации.
## Проверки
Добавлены проверки конкурентного создания пользователей и участия, нескольких победных счетов одного пользователя, повторного проведения/подтверждения/перерозыгрыша, прав и их отзыва, настоящих маршрутов aiogram с подменённым Telegram API, независимости диалогов, импорта/экспорта, пересылок и модерации.
CI запускает тесты на SQLite и отдельной PostgreSQL 16, соответствующей рабочему серверу. Проверка Alembic создаёт дополнительную временную БД, выполняет полную миграцию и обновление с рабочей ревизии, повторяет upgrade head и проверяет наличие ожидаемых таблиц/полей. SQLite используется для тестов сервисов через SQLAlchemy metadata; историческая цепочка миграций предназначена для PostgreSQL.
Итоговый локальный прогон с поддержкой премиум-эмодзи: **62 passed на PostgreSQL 15**; **60 passed, 2 skipped на SQLite** (пропущены PostgreSQL-тесты миграций). Оба прогона выдают по шесть предупреждений openpyxl об устаревающем `datetime.utcnow`; падений тестов нет. Поддержка эмодзи описана в [EMOJI_SYSTEM.md](EMOJI_SYSTEM.md).
Дополнительно прошли compileall, Ruff для критических ошибок, проверка состава релизного архива, поиск секретов в отслеживаемых файлах и синтаксическая проверка shell-скрипта. `pip-audit -r requirements.txt` сообщил `No known vulnerabilities found`. Это результат проверки известных уязвимостей зависимостей на дату аудита, а не гарантия безопасности всего приложения.
## Что ещё нельзя считать проверенным
1. **Drone и сервер.** Проверены SSH-доступ, права Docker, активность репозитория `trevor/new_lottery_bot` в `https://drone.smartsoltech.kr`. Настроены пять deployment-секретов. Успех удалённого deployment подтверждается отдельно после push; локальный зелёный прогон его не заменяет.
2. **Рабочая инфраструктура.** Docker-образ собран на целевом хосте. Эффективные настройки и volumes сопоставлены с действующим контейнером; PostgreSQL 16.15 на `192.168.20.2` доступен. Реальная проверка восстановления выявила несовместимость клиента pg_dump 17 с версией рабочей БД 16; образ закрепляет клиент 16 из официального PostgreSQL APT-репозитория. После исправления production backup успешно восстановлен в изолированном PostgreSQL 16, применена новая миграция и проверена схема; рабочая БД этой проверкой не изменялась. Автоматический откат приложения при искусственном сбое пока не проверялся.
3. **История секретов.** Удаление файла из будущего коммита не отзывает ранее записанные токен бота и пароль БД. Их нужно сменить и передать новые значения в Drone. История Git не переписывалась.
4. **Подтверждение клубной карты.** Текущая бизнес-логика принимает введённый пользователем номер карты без проверки по внешней системе или отдельного подтверждения кассиром. Она не доказывает, что карта принадлежит заявителю. Для устранения этого риска требуется определить источник проверки владельца; автоматического подтверждения такой принадлежности сейчас нет.
5. **Нагрузка и внешние сбои.** Тесты используют подменённые ответы Telegram и отдельные тестовые БД. Длительная нагрузка с реальными пользователями и потеря сети/Redis ещё не проверены. Рассылки не имеют долговременной очереди восстановления после рестарта; незавершённую рассылку может потребоваться повторить.
6. **Производственные данные.** Проверка перед выпуском не обнаружила дубликатов участников или призовых мест. Новая миграция повторяет эту проверку и останавливается при неоднозначных данных; она не удаляет их автоматически.
Инструкция по секретам и первому запуску: [DRONE_DEPLOYMENT.md](DRONE_DEPLOYMENT.md). Проверка выявленных дефектов не является гарантией отсутствия всех возможных ошибок.