You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Imagine you want to guarantee that you handle all messages with successful_payment. That is you
either somehow successfully responded to it (changed your state) or you want to receive and process
this update again (for example you crashed in the process).
Currently, you can implement this behavior for the long-polling if you use start_polling with handle_as_tasks=False, or for the webhook if you use SimpleRequestHandler with handle_in_background=False. The problem for me that in either case you control this behavior for
all updates.
For example with long-polling and disabled handle_as_tasks every single update will be handled
sequentially and after that the new request to Telegram will be made. I suggest to give user more
control how an individual update will be handled: sequentially or in the background. As an
alternative to solve the same problem, we can give user ability to process updates before they
handled: user can write updates to WAL and handle them on the next startup.
Possible solution
I will provide an example for the long-polling case.
The same idea can be applied for the webhook, but the implementation will be more intrusive.
Also, I'm not very experienced with writing backward compatible API in the Python.
aiogram version
3.x
Problem
Imagine you want to guarantee that you handle all messages with
successful_payment
. That is youeither somehow successfully responded to it (changed your state) or you want to receive and process
this update again (for example you crashed in the process).
Currently, you can implement this behavior for the long-polling if you use
start_polling
withhandle_as_tasks=False
, or for the webhook if you useSimpleRequestHandler
withhandle_in_background=False
. The problem for me that in either case you control this behavior forall updates.
For example with long-polling and disabled
handle_as_tasks
every single update will be handledsequentially and after that the new request to Telegram will be made. I suggest to give user more
control how an individual update will be handled: sequentially or in the background. As an
alternative to solve the same problem, we can give user ability to process updates before they
handled: user can write updates to WAL and handle them on the next startup.
Possible solution
I will provide an example for the long-polling case.
The same idea can be applied for the webhook, but the implementation will be more intrusive.
Also, I'm not very experienced with writing backward compatible API in the Python.
Currently,
start_polling
has the next signature:I propose change to this:
And change implementation of
Dispatcher._polling
from:To this (conceptually):
Alternatives
No response
Code example
Proposed change will allow handling specific messages sequentially or in the background:
or with WAL proposal:
Additional information
No response
The text was updated successfully, but these errors were encountered: