Bot stops responding after some period

[anpryl]

Bot stops responding after ~ 1 day. Only application restart helps.
Let me know if I can help you with debugging this issue.

[fizruk]

Thank you for reporting this issue! I will look at it closer later this week.

[anpryl]

I think it could be lost exception in https://github.com/fizruk/telegram-bot-simple/blob/master/src/Telegram/Bot/Simple.hs#L119 on request error

[fizruk]

@anpryl yes, there are actually two places in that function where exceptions might ruin things:

telegram-bot-simple/src/Telegram/Bot/Simple.hs

Line 119 in beae455

res <- getUpdates (GetUpdatesRequest offset Nothing Nothing Nothing)

and

telegram-bot-simple/src/Telegram/Bot/Simple.hs

Line 123 in beae455

mapM_ handleUpdate updates

Now when I was working on this before I was not concerned with exception handling for some reason.
For now, to fix your issue, you can simply ignore exceptions and try update in the next iteration.

However, I think it would be good to introduce a friendly way to deal with exceptions (or at least report them). The library design basically follows simple MVC like gloss, The Elm Architecture and Miso, and not one of those deals with user exceptions AFAIK (Elm does not even have those).

Perhaps we should merely add a new handler to the Bot definition:

import Control.Monad.Catch

data BotApp model action = BotApp
  { botExceptionHandlers :: [Handler BotM Action]
  , ...
  }

Then we could use it like this (untested):

shieldWith :: [Handler BotM Action] -> ClientM () -> ClientM ()
shieldWith handlers m = runBotM Nothing (BotM (lift m) `catches` handlers)

startPolling :: [Handler BotM Action] -> (Update -> ClientM ()) -> ClientM ()
startPolling handlers handleUpdate = go Nothing
  where
    go lastUpdateId = do
      ...
      res <- getUpdates (GetUpdatesRequest offset Nothing Nothing Nothing)
        `shieldWith` handlers
      ...
      mapM_ (flip runBotM (reader handleUpdate `catches` handlers)) updates
      ...

In the code above I need also to pass generated actions back for processing and probably run handlers in forks. We probably don't want to handle exceptions inside exception handlers. And we probably want to add a catch-all default exception handler to the end of botExceptionHandlers list.

@anpryl what do you think?

[anpryl]

@fizruk I like the idea to have separate exception handlers for handleUpdate.
But I doubt if it needed for getUpdates. I think that getUpdates exceptions should be logged with a subsequent retry. It might be a good idea to add LoggingT to allow library users control logging destination.