getaxe, нет, ничего не сломает. Просто будет срабатывать обработчик на тех событиях, на которых раньше не срабатывал. Но нужно будет проверять свойство partial и при необходимости делать fetch для получения отсутствующего в кэше объекта (он при этом также загрузится в кэш и при следующей реакции уже отработает без этой магии).
Partials как раз и позволяют получать события по объектам, которые не найдены в кэше и поэтому определены лишь ЧАСТИЧНО (например, известен id сообщения, но неизвестен текст, имеющиеся реакции и другие данные). По умолчанию такие события игнорируются, но можно уговорить библиотеку всё-таки их обрабатывать.
NonVer, на этом сайте помогают решать проблемы, а не решают их заместо спрашивающего. За готовым решением можно обратиться на фриланс, где "под ключ" сделают что угодно. А с вопросами сюда следует приходить хоть с какими-то попытками решения. Например, можно показать кусок собственного кода, вызывающий ошибку, или работающий не так, как ожидалось
lolrofl01, нельзя указывать цену продаваемого товара в валюте, если это, например, магазин предлагает товар широкому кругу лиц. В договоре между двумя сторонами можно использовать цену в валюте, при этом надо явно указать в какой и как определяется курс этой валюты (например, самое простое это по курсу ЦБ). Вообще, по словам "цена в долларах в договоре" в гугле довольно много результатов.
Например, если у каждой страницы есть номер, то при показе страницы N делаем кнопки с call_data=page:N-1 и page:N+1 (отдельно учитываем первую и последнюю страницу. При нажатии на кнопку редактируем сообщение, заменяя его текст на содержание страницы N+1/N-1 и кнопки на соответствующие.
serhiops, в обработчике команды ничего не надо отправлять. В нём нужно только добавить задание в очередь с указанием времени. Например (но необязательно!), очередь можно хранить в таблице в базе, для чего сделаем таблицу message_queue с такими полями:
id - главный ключ;
send_time - время отправки;
recipient_id - id получателся;
message - текст сообщения;
status - статус сообщений, пусть имеет значения awaiting или sent.
Вместо отправки добавим сообщение в таблицу в статусе awating (ожидает).
Регулярно пусть выполняется выгрузка из базы сообщений, которые ещё awaitng, но время уже наступило:
SELECT id,send_time,recipient_id,message FROM message_queue WHERE status='awaiting' AND send_time<NOW();
Извлечённые сообщения отправляем. Каждое переводим в статус sent, чтобы не отправить второй раз:
UPDATE message_queue SET status='sent' WHERE id=<id сообщения в очереди>;
Остаётся вопрос: как организовать регулярную выборку сообщений из очереди? Можно сделать по-разному:
1. Сделать отдельный тред в скрипте, который будет отслеживать очередь, перемежая это вызовами sleep. Или вместо треда таску в asyncio (если уже используется aiogram, то это более чем разумно).
2. Обрабатывать очеред в отдельном постоянно запущенном скрипте, либо запускать скрипт из cron каждую минуту.
Первый способ хорош тем, что всё в одном скрипте и потенциально очередь можно хранить не в базе, не в файле, не в брокере очереди типа rabbitmq, а прямо в переменной в скрипте. Правда, при этом в случае падения скрипта все запланированные задания на отправку будут потеряны. Второй хорош тем, что проблемы/тормоза скрипта отправке не будут вредить основному коду бота.
И, наконец, есть ещё один способ, при котором можно избежать организации очереди своими силами - использовать модули schedule/aioschedule (синхронный и асинхронный соответственно). Фактически, они берут на себя сохранение задания в очереди и вызов запрошенной функции в нужное время. Именно это тут посоветовали в первом ответе.
Mak_Sweet, где-то делаются запросы с этим токеном, то ли в этом боте, то ли в ещё где-то запущенном с таким же токеном.
По коду при поллинге none_stop=True приводит к тому, что бот делает повторные попытки, начиная с интервала 1/4 секунды и далее с увеличением в 2 раза последующие попытки. При этом ошибки будут логгироваться, но если событие в итоге обрабатывается, то это не страшно.
