И, если после выполнения задачи из массива, мы ее удалим, то в какой-то момент у нас будет массив из миллиона undefinedв нем, после которых снова добавляются новые задачи.
ты в курсе про shift? и зачем вообще у тебя тут рекурсия. Либо вообще используй нормальные очереди
MishaXXL, ты опять что-то придумываешь на ровном месте. Еще раз, "чтобы наш массив бесконечно не рос", из него надо удалять элементы, это вот прям элементарная логика.
MishaXXL, но тебе не нужно его перебирать, ты придумал проблему на ровном месте. Кроме этого, в реальности использую уже готовые реализации очереди, а не коленочное поделие
я так и не понял, что мешало тебе заменить with app: на async with app: и теперь ты зачем-то вместо async with явно руками вызываешь то, что у него под капотом? Ты точно понимаешь как это работает?
mayton2019, удачи тебе redis lock синхронно поставить в async коде или как ты где-то там предлагал с редис очередью поработать и воткнуть ее синхронное ожидание
Zettabyte, так я отвечал же уже, без проблем сохраняет в памяти состояния FSM, но если бота перезапустили, он упал и т.п., все они потеряны. Конечно можно их хранить в БД, но часто стейты, это не данные пользователя, а состояние меню в боте и прочая куча мелкой служебной инфы.
zven_bpe, в aiogram уже есть коннекты к редису, можно их использовать, ну и конечно же раз aiogram асинхронный, то и все задачи надо выполнять асинхронно
Алексей Уколов, стейты FSM он хранит, по умолчанию просто в памяти, любой перезапуск их теряет, для разработки ок, на для прода уже проблемы. Так же часто нужен менять уровень изоляции events_isolation, его можно делать через редис лок, очень помогает когда у тебя нагруженный бот и инстансев более чем один.
Dima163, в json такое не получить, он про хранение данных. Такое ты получишь когда сделаешь вывод поля output в конкретном месте, при условии что это место правильно понимает '\n'