Heroku部署的Telegram机器人对话处理器状态跳转异常求助

核心问题分析 #

你的Telegram机器人基于Django+python-telegram-bot(v13.15)开发，Webhook模式下本地运行对话处理器（Conversation Handler）正常，但部署到Heroku后，存在对话状态无法正常推进、消息被echo_handler拦截的问题，重发消息后才可恢复正常；而部署到Railway平台无此异常。结合Heroku的平台特性，问题大概率与对话状态存储机制、dyno运行特性相关。

排查与解决方向 #

1. 替换内存存储为持久化对话状态存储 #

python-telegram-bot v13默认使用MemoryStorage存储对话状态，这种进程内存储在Heroku环境下存在致命缺陷：

• 免费/基础版dyno空闲30分钟会自动休眠重启，重启后内存状态完全丢失；
• 若启用多个web dyno实例，每个实例的内存状态相互独立，用户后续请求落到不同实例时，无法读取之前的对话状态，导致流程中断，消息进入兜底的echo_handler。

解决方法：
实现基于Django数据库的自定义存储类，将对话状态持久化到数据库中。示例思路：

from telegram.ext import BasePersistence
from django.db import models
import pickle

# 定义Django模型存储对话状态
class BotConversationState(models.Model):
    chat_id = models.BigIntegerField()
    user_id = models.BigIntegerField()
    conv_name = models.CharField(max_length=100)
    state = models.BinaryField()  # 存储序列化后的状态
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        unique_together = ('chat_id', 'user_id', 'conv_name')

# 实现BasePersistence子类
class DjangoPersistence(BasePersistence):
    def __init__(self):
        super().__init__(store_user_data=True, store_chat_data=True, store_bot_data=True)
    
    def get_conversations(self, name):
        # 从数据库读取并反序列化对话状态
        states = BotConversationState.objects.filter(conv_name=name)
        return {
            (state.chat_id, state.user_id): pickle.loads(state.state)
            for state in states
        }
    
    def update_conversation(self, name, key, new_state):
        chat_id, user_id = key
        # 序列化状态后写入数据库，不存在则创建
        state_data = pickle.dumps(new_state)
        BotConversationState.objects.update_or_create(
            chat_id=chat_id, user_id=user_id, conv_name=name,
            defaults={'state': state_data}
        )
    
    # 按需实现其他必要方法：get_user_data、update_user_data、get_chat_data等

初始化Updater时指定持久化存储：

updater = Updater(token=bot_token, persistence=DjangoPersistence())

2. 禁用Heroku dyno休眠（针对免费/基础版） #

免费/基础版dyno无请求时会自动休眠，重启后内存中的对话状态全部丢失，导致正在进行的对话流程中断。

解决方法：

• 使用外部监控工具（如UptimeRobot）每25分钟向webhook URL发送请求，保持dyno活跃；
• 升级到Heroku专业版dyno，专业版无自动休眠机制。

3. 确保Webhook请求处理的原子性 #

Telegram的Webhook机制会在未收到200响应时重试发送更新，如果telegram_webhook视图在dispatcher.process_update未完全执行就返回200，可能导致Telegram重复发送同一更新，引发状态混乱。

解决方法：
确保dispatcher.process_update执行完成后再返回响应：

@csrf_exempt
@debug_requests
def telegram_webhook(request):
    if request.method == 'POST':
        json_string = request.body.decode('utf-8')
        update = Update.de_json(json.loads(json_string), updater.bot)
        # 等待处理完成后再返回响应
        dispatcher.process_update(update)
        return HttpResponse(status=200)
    else:
        return HttpResponseBadRequest('Invalid request method')

4. 临时限制Web dyno实例数量为1 #

如果启用了多个web dyno实例，每个实例的内存状态独立，会导致对话状态无法跨实例共享。

解决方法：
临时将web dyno数量设为1，测试问题是否消失：

heroku ps:scale web=1

若问题消失，说明是多实例状态不共享导致，必须使用持久化存储彻底解决。

5. 增加状态日志排查 #

在对话处理器关键节点添加日志，记录当前对话状态、dyno实例ID，确认状态是否正确存储和读取：

import os
from telegram.ext import CallbackContext

def customer_first_name_handler(update: Update, context: CallbackContext):
    # 记录dyno标识、对话ID和当前状态
    print(f"Dyno: {os.environ.get('DYNO')}, Chat ID: {update.effective_chat.id}, Current State: {context.user_data.get('conv_state')}")
    # 原有业务逻辑...

通过Heroku日志查看记录，判断是否存在状态丢失或实例不一致的情况。

内容的提问来源于stack exchange，提问作者RedArt