Handle upgrading a group to supergroup

[archydragon]

When a group where bot is present is upgraded, the following exception appears, and bot thread crashes:

Exception in thread "async-dispatch-23" clojure.lang.ExceptionInfo: clj-http: status 400 {:status 400, :headers {"Server" "nginx/1.12.2", "Date" "Fri, 12 Oct 2018 09:30:18 GMT", "Content-Type" "application/json", "Content-Length" "154", "Connection" "close", "Access-Control-Allow-Origin" "*", "Access-Control-Expose-Headers" "Content-Length,Content-Type,Date,Server,Connection"}, :body "{\"ok\":false,\"error_code\":400,\"description\":\"Bad Request: group chat was upgraded to a supergroup chat\",\"parameters\":{\"migrate_to_chat_id\":-1001158883424}}", :request-time 219, :trace-redirects ["https://api.telegram.org/bot***:*********/sendMessage"], :orig-content-encoding nil}
	at slingshot.support$stack_trace.invoke(support.clj:201)
	at clj_http.client$wrap_exceptions$fn__10012.invoke(client.clj:196)
	at clj_http.client$wrap_accept$fn__10216.invoke(client.clj:565)
	at clj_http.client$wrap_accept_encoding$fn__10222.invoke(client.clj:579)
	at clj_http.client$wrap_content_type$fn__10211.invoke(client.clj:554)
	at clj_http.client$wrap_form_params$fn__10303.invoke(client.clj:722)
	at clj_http.client$wrap_nested_params$fn__10317.invoke(client.clj:760)
	at clj_http.client$wrap_method$fn__10263.invoke(client.clj:670)
	at clj_http.cookies$wrap_cookies$fn__7643.invoke(cookies.clj:124)
	at clj_http.links$wrap_links$fn__8927.invoke(links.clj:51)
	at clj_http.client$wrap_unknown_host$fn__10326.invoke(client.clj:776)
	at clj_http.client$post.invokeStatic(client.clj:891)
	at clj_http.client$post.doInvoke(client.clj:887)
	at clojure.lang.RestFn.invoke(RestFn.java:423)
	at morse.api$send_text.invokeStatic(api.clj:35)
	at morse.api$send_text.invoke(api.clj:29)
	at morse.api$send_text.invokeStatic(api.clj:31)
	at morse.api$send_text.invoke(api.clj:29)
	at craplimiter_bot.handler$fn__10722.invokeStatic(handler.clj:23)
	at craplimiter_bot.handler$fn__10722.invoke(handler.clj:21)
	at morse.handlers$update_fn$fn__10686.invoke(handlers.clj:57)
	at morse.handlers$handling$fn__10663.invoke(handlers.clj:9)
	at clojure.core$some.invokeStatic(core.clj:2592)
	at clojure.core$some.invoke(core.clj:2583)
	at morse.handlers$handling.invokeStatic(handlers.clj:9)
	at morse.handlers$handling.doInvoke(handlers.clj:6)
	at clojure.lang.RestFn.applyTo(RestFn.java:139)
	at clojure.core$apply.invokeStatic(core.clj:648)
	at clojure.core$apply.invoke(core.clj:641)
	at morse.handlers$handlers$fn__10667.invoke(handlers.clj:15)
	at morse.polling$create_consumer$fn__10516$state_machine__5526__auto____10517$fn__10519.invoke(polling.clj:42)
	at morse.polling$create_consumer$fn__10516$state_machine__5526__auto____10517.invoke(polling.clj:42)
	at clojure.core.async.impl.ioc_macros$run_state_machine.invokeStatic(ioc_macros.clj:1011)
	at clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:1010)
	at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invokeStatic(ioc_macros.clj:1015)
	at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:1013)
	at clojure.core.async.impl.ioc_macros$take_BANG_$fn__5542.invoke(ioc_macros.clj:1024)
	at clojure.core.async.impl.channels.ManyToManyChannel$fn__464.invoke(channels.clj:135)
	at clojure.lang.AFn.run(AFn.java:22)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

Nevertheless, after the bot is restarted, it keeps working fine. But it would be good to not add some kind of trigger to restart bot in such cases :)

[Otann]

Thank you for reporting it!
The exception is something I don't understand and need to look into.

[archydragon]

I guess the reason is that when the group is upgraded, a new event is spawned by Telegram API, and when the bot polls it and if there is only a generic reaction to group events, it tries to send a response to the group but it doesn't exist anymore (when upgraded, its ID is changed). Wonder why it is treated as bad request by API.

[marksto]

There are two different things here:

1. The bot (an application using the Morse) must not crash upon receiving this type of response from the Telegram Bot API (HTTP 400 Bad request)

2. The official Telegram Bot API documentation states the following: "Some errors may also have an optional field 'parameters' of the type 'ResponseParameters', which can help to automatically handle the error". One may find the migrate_to_chat_id in the attached logs, so this is the case. That said, we might consider to introduce the auto-retry strategies for some/all of these cases. However, these strategies must be configurable and extendable by user.