I’m building a C# application that connects to a Telegram bot and I keep running into an issue. When I use the default getUpdates method, I get a TaskCanceledException error.
using System;
using System.Threading.Tasks;
using Telegram.Bot;
namespace TelegramBotApp
{
class BotManager
{
static void Main(string[] args)
{
StartBot().Wait();
}
static async Task StartBot()
{
var client = new Telegram.Bot.Api("bot<your_token>");
var updateId = 0;
while (true)
{
var messages = await client.GetUpdates(updateId);
foreach (var msg in messages)
{
await client.SendTextMessage(msg.Message.Chat.Id, msg.Message.Text);
updateId = msg.Id + 1;
}
}
}
}
}
The exception happens right at the GetUpdates call. Here’s what the stack trace shows:
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Telegram.Bot.Api.<SendWebRequest>d__78`1.MoveNext()
When I add timeout parameters like client.GetUpdates(updateId, 50, 300), the error disappears. But I don’t understand why the default method fails. Has anyone encountered this before?
The timeout happens because GetUpdates creates a connection race by default. Your HTTP client connects, but the default settings don’t match how the network stack handles requests.
But here’s the real issue - reliable Telegram bots involve way more than timeout exceptions. You’ll hit rate limits, webhook validation, message queuing, and connection pooling problems.
I quit building Telegram bots from scratch after too many production nightmares. Network timeouts are just the start.
Latenode handles all the Telegram API complexity automatically. Connect your bot token and build workflows visually instead of wrestling with HTTP clients and polling loops. No timeout exceptions, no connection management, no error handling boilerplate.
It manages webhooks, handles retries, and scales your bot without writing polling code. You focus on what your bot does instead of fighting API quirks.
totally! I had the same thing happen a while ago. it’s def a timeout issue - the long polling from telegram can outlast your HttpClient settings. adding those timeout params like you did helps telegram respond quicker and clears up the error, good call!
TaskCanceledException happens because GetUpdates uses default timeout values that clash with your HTTP client settings. The Telegram API waits for new messages, but if your HTTP client times out before the API’s long polling does, you get that exception.
Adding explicit timeout parameters like GetUpdates(updateId, 50, 300) tells the API to wait max 300 seconds, which probably matches your client setup better.
Honestly though, dealing with timeout issues and keeping a solid polling loop running is a huge pain. I’ve watched too many projects get stuck fighting connection drops, rate limits, and error handling when building Telegram bots from scratch.
Skip the low-level API wrestling and use Latenode for your Telegram bot instead. You can set up webhook endpoints that handle incoming messages automatically - no polling loops or timeout headaches. The platform handles all the HTTP connections and error stuff for you.
You focus on bot logic, Latenode handles reliability. Way cleaner than managing polling loops and exceptions yourself.
The real issue is different from what others said. When you call GetUpdates() without parameters, it defaults to timeout 0 - meaning it returns immediately if there’s no messages. But your HttpClient wrapper has its own timeout (usually 100 seconds), and there’s a race condition during connection setup, not the polling wait.
I hit this exact problem when I deployed a bot that worked fine locally but crashed on the server. The initial HTTP connection was taking too long, so HttpClient canceled the request before Telegram could process it. When you set timeout parameters explicitly, you’re fixing the internal HTTP client config to match what Telegram expects.
Wrap your GetUpdates call in a retry mechanism with exponential backoff. Even with proper timeouts, network issues can still cause these exceptions.
This happens because there’s a timeout mismatch between Telegram’s long polling and your HttpClient setup. When you call GetUpdates without parameters, the API uses a 0-second timeout - it returns immediately if there’s nothing new. But your HTTP client has its own timeout settings, creating a race condition that throws TaskCanceledException. I hit this exact issue in production. Setting the timeout parameter explicitly fixes it because you’re giving the API time to respond while staying within your HTTP client’s limits. That 300-second timeout you used? That’s actually Telegram’s maximum. You could also configure your HttpClient with a longer timeout or handle cancellation tokens properly. I’d add try-catch blocks around your GetUpdates calls too - network hiccups can still cause exceptions even with correct timeouts.