Telegram bot R command handler not responding to @bot_name format

Other Questions Telegram bot
1

I’m working with the telegram.bot package in R and running into a weird problem. My bot responds perfectly when I send /start command directly, but it completely ignores the same command when it’s formatted as /start@bot_name.

From what I understand, both formats should work exactly the same way, especially in group chats where you need to specify which bot you’re talking to. But for some reason, my bot only catches the plain command without the bot name suffix.

Here’s my current setup:

library(telegram.bot)

bot_token <- "YOUR_TOKEN_HERE"
bot <- Bot(token = bot_token)
chat_id <- "CHAT_ID_HERE"

updater <- Updater(token = bot_token)

# start function
start <- function(bot, update){
  bot$sendMessage(chat_id = update$message$chat_id,
                  text = sprintf("Hello %s!", update$message$from$first_name))
}

start_handler <- CommandHandler("start", start)
updater <- updater + start_handler

# start bot
updater$start_polling()

Any ideas what might be causing this issue? I’ve checked the BotFather settings but can’t find anything obvious that would fix this behavior.

2

Yes, the behavior you’re encountering with the telegram.bot package is due to the exact string matching of the CommandHandler. It treats /start and /start@bot_name as distinct commands. To resolve this, I implemented a preprocessing function that strips the bot’s name from the command before it’s processed by the handler. You can intercept the message text, split it at the ‘@’ character, and use just the first part for the command handling. Alternatively, using a MessageHandler with a custom filter to parse the command can also be effective. This issue remains as is, as changing it might disrupt the established CommandHandler functionality.

3

I ran into this exact issue a few months ago. The telegram.bot package doesn’t automatically strip the bot name from commands like /start@bot_name before matching them to your handler - you’ve got to handle this yourself. Here’s what worked for me: create a custom message handler that checks for both patterns, or make your CommandHandler more flexible with regex matching. You can also use a MessageHandler with a custom filter function that processes the command text first. This is actually documented in some GitHub issues for the package, but it’s buried and not obvious from the main docs.

4

had the same headache last week! CommandHandler(“start”, start) only matches /start exactly - won’t catch /start@yourbot. quick fix: manually parse update$message$text and strip everything after the @ before processing. works perfectly in group chats after that.