- Notifications
You must be signed in to change notification settings - Fork5.7k
Description
Is your feature request related to a problem? Please describe.
Clients allow users to spam button presses. This leads to race conditions where the code edited the reply_markup and then tries to edit again even though it was already edited because several updates resulted from the same button.
Describe the solution you'd like
I would like to have the library handle these race conditions with some simple code checks and not propagate these repeated updates to the handlers.
Doing this for non async handlers is very easy. All this library needs to store is the callback_data from the first inline button send/edit_message request, and then the callback_data from the next one or a deleted flag if the reply_markup is removed; all this valued to a unique key from chat+message_id or inline_message_id. If then an update happens which has the first callback_data even though the next one is expected, or another callbackquery update happens when the delete flag is set, the query should be answered (for this, maybe the answer value should be stored as well) and then the update dismissed.
I am not sure how to handle this for async handlers, but I think we could try and apply the same logic, and warn in the docs that it can just happen that two Updates slip through. I hope someone here can think of a better way to handle this. One alternative would be to not handle a multiple update with the same callback_data from the unique key. But that could lead to an issue where something else in the code breaks temporarily, and a user isn't able to try hitting the button again after some time when that issue is resolved. Maybe we can work with try expect for that?
Describe alternatives you've considered
This can be easily implemented client side, and with minimal coding effort with a decorator. I vote against this for two reasons: I would need to do this for every callbackqueryhandler manually, and I mostly think beginners will overlook this issue. Then they are facing errors they cant understand because no one thinks about spamming a button that fast.