visciang
commented
1 year ago IMHO it is a bad design choice to expose this behavior.
As aigram describe it should not b be used in production ... so when should be used and why?
Let me elaborate on that.
The telegram server owns a queue of messages for our bot, messages have TTL and delivery policy / retry telegram side. These depend on the delivery method we use to get updates - polling or webhook.
What does it means to "flush" the queue when the bot starts? And what if the bot or app restart for whatever reason? Should we discard all messages received meanwhile?
And how can we flush if we use a webhook (the dispatch method we should use in production)? We can flush with a tight loop when we are in polling mode but ...
Or should we apply a TTL on our side discardimg messages sent before a predefined Delta from the time it is received? And then what if the bot is slower to process messages than they are sent and they get "old"? Should we throw them away?
I think that if there are some business rules in our bot that encode (and trust) a specific time dependent behavior they could be encoded in the bot itself. At the end it's just a (bot specific) reject function to be wired in the handle update function.
To summarize I think it would be a bad/leaky abstraction to expose any of these specific behavior at framework level.
What do you think about function "skip_updates" to prevent messages handling after bot starts? (I mean functionality like aiogram has)
How it is going now: Bot is stopped --> we send message to bot --> we starting our bot --> it handles all the messages came before.
How it is supposed to be: (skip_updates=true) Bot is stopped --> we send message to bot --> we starting our bot --> bot doesn't know nothing about the messages before its start.