1. Бот всегда работает асинхронно. 2. При обработке апдейтов - бот будет "молчать" пока всех их не обработает. За 1 раз ему телега отдаёт 100 апдейтов. Рекомендую выставить skip_updates=True
Но мне эти апдейты кровь из носу важны
Значит придется ждать
а чего у тебя бот с важными апдейтами в даунтайме 2 часа?
я случайно выключил)
🧐. Я даже специально иногда не могу вырубить бота. А тут такое)
Я когда пишу бота то файл перекидываю на сервер и там делаю systemctl start systemctl stop
В докер лучше закинь. Жизнь упростишь себе
Я обычно внутри гитлаба проверяю наличие системди файла и через CICD делаю запуск. Ну и рестарт с подгрузкой новых файлов конечно
Сделал пуш и бот обновился, не вижу проблем
Муторно как-то) Хотя для частообновляемых проектов в самый раз
Да ладно, 1 раз написал и потом по шаблону
для любых проектов все что не надо делать руками - прекрасно
git pull && ./deploy.sh
git push и забыл
Оп и непредвиденная оишибка в боте) Логи не отдаёт, не стартует и прочее) Что делать будем?
2 не совсем верно. Я бы даже сказал, совсем не верно. Если впихнуть там везде условный asyncio.sleep или что-то другое с ожиданием, то бот успеет ещё несколько раз новые апдейты забрать
Учти что апдейты последовательно прилетают. И учти что главное не попасть в флудвейт
Изначально стоит задача обработать все апдейты без исключения, поэтому ставить слипы и ловить следующую пачку не обработав прошлую особо смысла нет
обработаный апдейт это когда код в функции хендлера дойдет до конца?
Я говорил условно. Там может быть какой-то очень долгий запрос сетевой или к бд
Это когда ты принял апдейт, пустил по мидлвари, фильтрам, хендлерам и ответил/не ответил куда надо.
если тут синхронный скулайт это может быть причиной долгого ответа или особой роли не играет?
Вообще желательно всё в асинк переводить. Даже БД. Теоретически синхронный скулайт будет заметно тормозить бота при средних и высоких нагрузках
Ну у меня два бота, второй сидит на aiosqlite. Думаешь и этого перетянуть на него?
Я бы вообще постгрес юзал. Для малых проектов скулайт адекватный вариант. Но если планируется что-то более масштабное - то лучше уже постгрес или монгу юзать
да я бы с радостью, но там совершенно по другому всё, я повешусь всё переписывать под постгре
Запросы в 90% случаев одинаковы. Максимум создание таблиц малость переписать и по запросам проверить всё
а если записей 2 ляма?
С таким количеством - уже надо было перейти на постгрес)
ну мб по мануалу груши как то перепишу, но чуствую что это будет часов на 15 и с кучей ошибок и багов
Можешь как в сыром виде сделать (asyncpg), так и на алхимию перейти
Обсуждают сегодня