-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
polling/start
cannot signal when the updates channel is closed
#28
Comments
Are u sure to it resolve a problem the best way? I know clojure a little bit, but I also know that @Otann said you need to catches exceptions in the handler (#17) My solution: (defonce telegram-poller (atom nil))
(defn -main
[& args]
(defn start
[]
(go
(try
(reset! telegram-poller (p/start token bot-api))
(catch Exception e
(println (.getMessage e))
(start)))))
(start)
(Thread/sleep Long/MAX_VALUE)) It works well, but it's definitely not a best practice too :) |
@chiliec I haven't been able to track down what causes the polling to stop, looking through my logs I don't see any exceptions that might cause this (although I might have missed it.) I think @Otann's advice in #17 is good but from reading the code it looks like it's possible for |
@jonathanj hello Jonathan! thank you for the request.
|
Ah! I see your point now, are you asking for something like this? (defn start
"Starts long-polling process.
Handler is supposed to process immediately, as it will
be called in a blocking manner."
([token handler] (start token handler {}))
([token handler opts]
(let [running (chan)
updates (create-producer running token opts)
consumer (create-consumer updates handler)]
[running consumer]))) As this should not happen at all, I feel hesitant doing it. @chiliec is right, restarting things when they break is not the best practice ;) I would very much like to fix the root cause and add another Could you try the piece of code above and share your logs/ideas on what causes the stop? |
What's wrong with restarting things when they break? If the Telegram transport fails (because I have no Internet for 12 hours, for example) either Morse needs to implement retrying (which is at the wrong level, in my opinion, because how and when to retry should be my decision) or my application needs to implement retrying, which it can't do because there is no way for it to know whether the Morse polling loop is alive or not. It would be nice to know what the root cause is, definitely, unfortunately I haven't managed to figure that out yet. The issue doesn't happen that often for me, so the debugging iteration loop is quite long. |
@jonathanj nothing is wrong with restarting, what is wrong is when things break. Things should not break ;) I'm thinking on a proper solution, which will give you that. |
Recently got a similar issue (stopped long polling) and saw this exception:
I found that the updates channel gets closed in case of the exceptions like this:
To me it seems quite clean to wrap get-updates into try-catch since it's interacting with real world and shouldn't break the application logic in case of any exception. |
This particular thing just happened to me now, I'm sure it's not the only thing causing this but in this case morse isn't restarting properly but I also can't do anything about it from an application perspective, like a bit later retry or use a fallback delivery mechanism or inform someone. |
@jonathanj @dixel @chiliec I added a small piece that closes Released this as |
@Otann This sounds ideal, I'll upgrade my dependencies. I'm going to close the ticket since the code looks like it solves the issue. Thank you! |
I have a problem where my bot no longer receive messages over Telegram, until I restart my application. This usually happens over long-ish period (about 24 hours) and I don't have the best Internet connection.
Reading the code for
morse.polling
it appears thatmorse.polling/start
has no way to signal that it is no longer polling, and so a user will never know to callstart
again.create-consumer
returns a channel that will contain exactly one result when the loop exits (as a result ofupdates
being closed.) Ifstart
returned the result ofcreate-consumer
instead of therunning
channel, that will never be closed, it would be possible for user code to restart in the event of the polling loop dying:I'm happy to submit a PR if you don't have time or the inclination to do this yourself, @Otann.
The text was updated successfully, but these errors were encountered: