Problem

Telegram message processing was completely sequential, blocking all messages while one was being handled. This made the maxConcurrent config setting ineffective for Telegram users.

Root Cause

grammY's default bot.start() uses sequential update processing:

// node_modules/grammy/out/bot.js
async handleUpdates(updates) {
    // handle updates sequentially (!)  <-- grammY's own comment!
    for (const update of updates) {
        await this.handleUpdate(update);  // Blocks until complete
    }
}

This meant:

• While responding to one chat, ALL other Telegram messages queued
• Ack reactions (👀) didn't appear until the queue cleared
• Long-running tool calls blocked every other conversation
• Multi-chat parallelism was completely broken

How Other Providers Handle This

Discord and WhatsApp already processed messages in parallel. Only Telegram was affected.

Visual Example

Before (sequential):

Msg A arrives → handler starts → [30 sec tool call] → handler ends
Msg B arrives → [BLOCKED 30 sec] → handler starts → ...
Msg C arrives → [BLOCKED 60 sec] → ...

After (concurrent with runner):

Msg A arrives → handler starts in parallel →
Msg B arrives → handler starts in parallel →
Msg C arrives → handler starts in parallel →
(all processing concurrently, limited by maxConcurrent)

Solution

Use @grammyjs/runner which is the official grammY plugin for concurrent update processing.

Changes

1. Added @grammyjs/runner dependency
2. Replaced bot.start() with run(bot) in src/telegram/monitor.ts
3. Proper abort signal handling for graceful shutdown

Code Change

- await bot.start();
+ const runner = run(bot, {
+   runner: { fetch: { timeout: 30 } },
+ });
+ await runner.task();

Benefits

• ✅ Ack reactions (👀) appear immediately
• ✅ Multiple chats processed in parallel
• ✅ maxConcurrent setting now works for Telegram
• ✅ Long tool calls don't block other conversations
• ✅ Consistent behavior across all providers

Testing

Tested on dev container with:

• Rapid messages to DM and group simultaneously
• Both processed concurrently without blocking
• Verified parallel execution in logs

Related

This was discovered while investigating why ack reactions were delayed. The deeper issue was that the entire Telegram provider was single-threaded.