Description
Hi,
I think I have encountered a bug in the getUpdates
handler. What happens is following: if my bot doesn't receive a message for a longer period of time, then it breaks on a first message by going into endless loop.
Behavior
Here is the app log (with debug turned on):
# this is happily repeated over and over and over
2018/03/20 14:33:34 getUpdates req : map[offset:[727334708] timeout:[60]]
2018/03/20 14:33:34 getUpdates resp: []
2018/03/20 14:34:25 getUpdates resp: {"ok":true,"result":[]}
...
# BUT!
2018/03/20 14:37:18 getUpdates req : map[timeout:[60] offset:[727334708]]
2018/03/20 14:37:18 getUpdates resp: [{UpdateID:117314199 Message:0x10a89540 EditedMessage:<nil> ChannelPost:<nil> EditedChannelPost:<nil> InlineQuery:<nil> ChosenInlineResult:<nil> CallbackQuery:<nil> ShippingQuery:<nil> PreCheckoutQuery:<nil>}]
2018/03/20 14:37:18 getUpdates resp: {"ok":true,"result":[{"update_id":117314199,
"message":{"message_id":64,"from":{"id":protected,"is_bot":false,"first_name":"protected","last_name":"protected","username":"protected","language_code":"en-BE"},"chat":{"id":protected,"first_name":"protected","last_name":"protected","username":"protected","type":"private"},"date":1521553038,"text":"protected"}}]}
Only after the restart is this message processed and new messages can come in.
Cause
Based on this text from page https://core.telegram.org/bots/api I believe this is the cause (it's beside the update_id
)
The update‘s unique identifier. Update identifiers start from a certain positive number and increase sequentially. This ID becomes especially handy if you’re using Webhooks, since it allows you to ignore repeated updates or to restore the correct update sequence, should they get out of order. If there are no new updates for at least a week, then identifier of the next update will be chosen randomly instead of sequentially.
So, as you can see the id of the update is not any more higher than the offset, but lower, thus a problem arises since the message is not sent at all to the update message handler
I think there are 2 bugs here in fact:
- endless loop could be avoided
- the offset value can be ignored and smaller value can come in