v2.9.1 — a group that becomes a supergroup no longer takes the bot down with it
Both of these come out of @famewolf's debug log in #2, and the first one is the reason his bots went quiet.
A group that becomes a supergroup no longer takes the bot down with it
His log had it four times over:
Telegram API 400: Bad Request: group chat was upgraded to a supergroup chat
When Telegram converts a group to a supergroup it changes the chat id, from -52… to -100…. That breaks both directions at the same moment, which is why it looks total rather than partial: sends are refused, and incoming messages now carry the new id, so they no longer match CHAT_ID and get dropped as unauthorised. The bot starts, announces itself, registers its 27 commands — and answers nothing.
And we had the answer in our hands the whole time. That 400 carries parameters.migrate_to_chat_id: the new id, from Telegram, in the very response we were already printing. We printed the description and threw the parameters away.
So it follows the rename now. It picks up the new id, resends the message that was refused instead of losing it, accepts commands from the group under its new id, and tells you — in the log and once in the chat — exactly which value to change.
It is deliberately not saved to settings.json. A saved value outranks the environment, so persisting it would only swap this problem for the one where a corrected CHAT_ID in your compose file is silently ignored. And since a bot that only ever listens never meets that 400, the first rejected command asks Telegram once whether the chat has merely moved.
The two places a command can be dropped now say why
Both were silent unless DEBUG=true: an incoming chat.id that does not match CHAT_ID, and a sender who is not on TELEGRAM_ALLOWED_USERS. That is a nasty dead end — the / picker even offers you the commands, because the bot did register them, and then nothing happens with no error anywhere.
Each reason is named once per boot now, with the real ids, and the allow-list one mentions that a value in settings.json beats your compose file. Once and not per message, because the silence had a reason too: drive-by messages in a shared group would otherwise bury the log. Log only, never a reply into the chat — answering an unauthorised chat would confirm the bot is there and name the machine it watches, which is the whole point of refusing.
Nothing to do on upgrade. If your bot has gone quiet in a group, this version will say why on the first command.
