ChatManager: как научить бота помнить, где ему работать

Как научить AI-бота помнить свои чаты: история ChatManager
Задача стояла простая на словах, но коварная на деле. У AI-бота в проекте voice-agent началась проблема с идентичностью: он рос, его добавляли в новые чаты, но вот беда — он не различал, в каких группах он вообще должен работать. Представь: бот оказывается в сотне чатов, а слушаться команд должен только в тех, которые явно добавил его хозяин. Без этого механизма вся система на мине.
Первым делом разобрали задачу по кирпичикам. Нужна была полноценная система управления чатами: бот должен помнить, какие чаты ему доверены, проверять права пользователя перед каждой командой и предоставлять простые способы добавлять/удалять чаты из управляемых. Звучит как обычная CRUD-операция, но в контексте асинхронного Telegram-бота это становится интереснее.
Решение разделили на пять логических контрольных точек. Начали с ChatManager — специального класса в src/auth/, который ведал бы всеми чатами. Важное решение: использовали уже имеющийся в проекте structlog для логирования вместо того, чтобы добавлять ещё одну зависимость. И, что критично для асинхронного бота, выбрали aiosqlite — асинхронный драйвер для SQLite. Почему это важно? Потому что обычный SQLite работает синхронно и может заблокировать весь бот при обращении к БД. aiosqlite оборачивает операции в asyncio — и вот уже БД не стопорит главный цикл обработки сообщений.
Дальше пошли миграции и middleware. Создали таблицу managed_chats с информацией о чатах, их типах и владельцах. Затем встроили в pipeline Telegram-хэндлеров специальный middleware для проверки прав — перед каждой командой система проверяет, имеет ли пользователь доступ к этому чату. Если нет — молчит или вежливо отказывает.
Команды управления (/manage add, /manage remove, /manage list) сделали простыми и понятными. Напишешь в личку боту /manage add — и чат добавляется в управляемые. Никакого магического угадывания, всё явно.
Интересный момент про асинхронные БД. Когда разработчики впервые натыкаются на проблему “бот зависает при запросе к БД”, они часто виноваты в синхронных операциях с базой. aiosqlite решает это элегантно: минимум кода, максимум производительности. Это один из тех инсайтов, которые приходят дорого, но в долгосрочной перспективе спасают душу.
В итоге получилось мощно. Бот теперь точно знает, кто его хозяин в каждом чате, и не поддаётся на трюки неуполномоченных пользователей. Архитектура масштабируется — можно добавить роли, разные уровни доступа, историю изменений. Всё работает асинхронно и не тормозит. Дальше очередь интеграционных тестов и production.
😄 Совет дня: всегда создавай миграции БД отдельно от логики — так проще откатывать и тестировать. И да, GCP и кот похожи тем, что оба делают только то, что хотят, и игнорируют твои инструкции.
Метаданные
- Session ID:
- grouped_C--projects-bot-social-publisher_20260209_1150
- Branch:
- main
- Dev Joke
- Что общего у GCP и кота? Оба делают только то, что хотят, и игнорируют инструкции
Часть потока:
Разработка: bot-social-publisher