Currently, exceptions (like undefined) in actions handler would kill the thread that reads the action's queue, but not the others. This causes TBS to populate TQueue with new actions, but not call user's code to execute them. This leads to the bot doing nothing and consuming more and more memory, which is not the desired behavior.
As shown in the code, we don't catch any exceptions and forkIO doesn't propagate them up. There are two ways to elaborate this issue:
We may address the current issue only by adding a catchError call, which would report any exception and continue processing actions.
Another solution is to rewrite all these forkIO into async and link, so any exception would be propagated at the top. This solution would solve all possible issues with exceptions and give users more control over how they would like to treat exceptions, for example, by allowing them to choose to either crash or restart TBS. The first solution only allows for the bot to be restarted.
Currently, exceptions (like
undefined
) in actions handler would kill the thread that reads the action's queue, but not the others. This causes TBS to populateTQueue
with new actions, but not call user's code to execute them. This leads to the bot doing nothing and consuming more and more memory, which is not the desired behavior.The issue is caused by this
forkIO
call: https://github.com/fizruk/telegram-bot-simple/blob/master/telegram-bot-simple/src/Telegram/Bot/Simple/BotApp/Internal.hs#L120As shown in the code, we don't catch any exceptions and
forkIO
doesn't propagate them up. There are two ways to elaborate this issue:catchError
call, which would report any exception and continue processing actions.forkIO
into async and link, so any exception would be propagated at the top. This solution would solve all possible issues with exceptions and give users more control over how they would like to treat exceptions, for example, by allowing them to choose to either crash or restart TBS. The first solution only allows for the bot to be restarted.