How to ensure updates queue does not get stuck indefinitely when there's one error? #205
-
When using the webhook setup, it seems like Telegram requires a successful HTTP response before it sends the next update in the queue. This makes sense in many cases, because you don't want to receive the updates out-of-order. However, it also means that when there's a bug in command, which may not respond with a HTTP success code, all further commands will fail. Essentially breaking the bot permanently. Or at least until that one command is fixed. Right now I'm considering something like the below, but I'm curious how other developers are working around this? def process(*)
super
rescue StandardError => e
logger.info e
respond_with :message, text: "Whoops. Something went wrong."
end |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
I would say that the way of processing errors will depend on the application, as somebody may want to stop accepting requests until app is fixed. Your option is good to go with. You may want to consider adding support for other types of responses, such as callback and/or inline queries. Here is the code from one of the bots: def process(*)
super
rescue StandardError => e
raise e if Rails.env.test?
logger.error { ([e.message] + e.backtrace).join("\n") }
Rollbar.error(e)
respond_with_error(e)
# suppress error because telegram will resend requests otherwise
end
def respond_with_error(error)
text = "#Error: #{error}" # suitable only for trusted chats
if callback_query?
answer_callback_query(text)
edit_message :reply_markup, reply_markup: {inline_keyboard: []}
end
pin_message { reply_with(:message, text: text, reply_to_message_id: reply_to_message_id) }
end
def pin_message(message = nil)
message ||= yield.fetch('result')
bot.pin_chat_message(chat_id: message['chat']['id'], message_id: message['message_id'])
message
end |
Beta Was this translation helpful? Give feedback.
I would say that the way of processing errors will depend on the application, as somebody may want to stop accepting requests until app is fixed. Your option is good to go with. You may want to consider adding support for other types of responses, such as callback and/or inline queries. Here is the code from one of the bots: