Google Apps Script Telegram bot commands not responding correctly

[Pete_Magic]

I’m having issues with my Telegram bot built in Google Apps Script. Some commands work perfectly while others don’t get recognized at all.

function processUserCommands(userInput, chatIdentifier, msgId) {
  if (userInput.toLowerCase() === '/register') {
    initializeRegistration(chatIdentifier, msgId);
  } else if (userInput.toLowerCase() === '/getfiles') {
    initializeFileRequest(chatIdentifier, msgId);
  } else if (userInput.toLowerCase() === '/farmdata') {
    initializeFarmInfo(chatIdentifier, msgId);
  } else if (userInput.toLowerCase() === '/location') {
    initializeLocationCheck(chatIdentifier, msgId);
  } else if (userInput.toLowerCase() === '/verify') {
    initializeVerification(chatIdentifier, msgId);
  } else if (userInput.toLowerCase() === '/about') {
    initializeAboutSection(chatIdentifier, msgId);
  } else if (userInput.toLowerCase() === '/refresh') {
    initializeSystemRefresh(chatIdentifier, msgId);
  } else if (userInput.toLowerCase() === '/commands') {
    initializeHelpMenu(chatIdentifier, msgId);
  } else if (userInput.toLowerCase() === '/clear') {
    clearUserData();
  } else if (userInput.toLowerCase() === '/start') {
    sendBotMessage(chatIdentifier, msgId, "Hello! Bot is currently online and ready.");
  } else {
    sendBotMessage(chatIdentifier, msgId, `Hello! Please use /commands to see available options`);
  }
}

The weird thing is that /getfiles and /farmdata always trigger the default else statement instead of their specific functions. All other commands work as expected. I tested the exact same code in a fresh Apps Script project with a new bot and everything works there. What could cause this difference between the two projects?

[emmat83]

sounds like a timing issue or dup webhook handlers. I’ve seen this b4 - certain cmds get processed by old cached code versions in Apps Script. deploy as a new version instead of just saving. that usually clears the execution cache. also check if those cmds have async calls that might timeout differently between projects.

[elizabeths]

Check your webhook setup and execution transcript carefully. I had the exact same issue when my Apps Script project had multiple webhook endpoints or old triggers still running. The broken commands were getting caught by deprecated functions. Go to your Apps Script project triggers, delete ALL of them, then recreate your webhook trigger from scratch. Apps Script sometimes keeps ghost triggers that aren’t visible but still process requests. Your doPost function might also be the problem if you’re using webhook mode. Make sure you’re extracting command text the same way every time. My issue was in the message parsing logic - certain commands got preprocessed differently because of conditional statements earlier in the execution chain. Add console.log statements in your doPost function before calling processUserCommands to see exactly what string gets passed. The working project probably has cleaner message extraction.

[deltaDreamer]

The Problem: Your Telegram bot, built using Google Apps Script, is experiencing intermittent command recognition failures. Commands /getfiles and /farmdata consistently trigger the default “else” statement, while all other commands function correctly. This issue is specific to your current project; a fresh Apps Script project with identical code works without problems. This suggests an issue with the project’s environment or configuration, rather than a flaw in the bot’s logic.

Understanding the “Why” (The Root Cause):

The inconsistency between your malfunctioning project and a new, functioning one points towards environment-specific factors. The most likely culprits are:

• Invisible characters or encoding issues: Hidden characters or incorrect encoding in your command strings (/getfiles, /farmdata) can cause the userInput.toLowerCase() comparison to fail. These characters might be invisible to the naked eye, but they interfere with string equality checks. Copying and pasting code between projects can introduce these problems.
• Cached execution or old webhook data: Google Apps Script’s interaction with Telegram webhooks can sometimes lead to caching issues. Old, stale data or outdated trigger configurations might be causing the bot to process commands with incorrect or outdated code.
• Modifications to userInput variable: A function executing before processUserCommands might be inadvertently modifying the userInput variable for /getfiles and /farmdata before the command processing stage, altering the strings in such a way that the if/else if statements no longer match.
• Webhook URL or trigger misconfigurations: Discrepancies between the webhook settings in your problematic and working projects could lead to unexpected behavior. This might involve different webhook URLs or trigger parameters that affect how commands are handled.

Step-by-Step Guide:

1. Verify Command Strings: Manually retype the /getfiles and /farmdata checks within the processUserCommands function. Do not copy and paste. Pay close attention to any extra spaces or characters, even those appearing as blank spaces.
2. Check for Invisible Characters: Add logging statements to visually inspect the userInput variable within processUserCommands. Use Logger.log('Received input: "' + userInput + '" Length: ' + userInput.length); right at the start of the function. This will help you identify any hidden or unexpected characters.
3. Examine Pre-processing: Carefully review any functions called before processUserCommands. Ensure no function modifies or manipulates the userInput variable in a way that is command-specific or otherwise unexpected.
4. Delete and Recreate Webhooks: In your Google Apps Script project, go to the Triggers section. Delete ALL triggers related to your Telegram bot. Then, recreate the webhook trigger from scratch, making sure to double-check the webhook URL and related settings.
5. Compare Webhook Configurations: Compare the webhook configurations (URL, triggers, etc.) of your problematic project with your working project to identify any inconsistencies.
6. Deploy a New Version: Deploy your Apps Script project as a completely new version rather than simply saving changes. This often clears execution caches which could be contributing to the issue.
7. Investigate Asynchronous Calls: If /getfiles and /farmdata use asynchronous operations, review their timeout settings and ensure they’re consistent in both projects. Potential timeouts can lead to different responses.

Common Pitfalls & What to Check Next:

• Character Encoding: Ensure consistent character encoding throughout your codebase. Incorrect encoding can lead to unexpected character translations.
• Whitespace: Pay close attention to leading, trailing, or extra whitespace in your command strings. Trim whitespace using .trim() before comparison.
• Case Sensitivity: While the code uses toLowerCase(), verify there is no unintentional case-sensitive comparison elsewhere.
• Debugging: Implement additional Logger.log() statements throughout your code to track the userInput variable’s value at various points, allowing you to pinpoint where the modification occurs.

Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!

[Oscar64]

Check if you’re accidentally modifying the userInput variable before it hits the command processor. I had the same issue - turned out another function was trimming or processing the input string differently for certain commands. Could also be webhook config differences. Your working project might use a different webhook URL or trigger settings. Hit up your Apps Script dashboard and compare the webhook URLs and triggers between both projects. Add some logging right at the start of processUserCommands to see exactly what userInput contains when those commands fail. Try: Logger.log(‘Received input: "’ + userInput + '" Length: ’ + userInput.length). This’ll show hidden characters or weird formatting. Also check if you’ve got other functions in the broken project intercepting those specific commands before they reach processUserCommands. Old code or duplicate handlers love to mess with command processing.