3 Commits

Include renames

Author	SHA1	Message	Date
Steven	2170a0664d	fix(integrations): 重启后机器人要能自己接回来 ... 上一版把双进程抢会话修了，但生产重启后仍然不收消息：`start_all()` 是进程启动时的 查询，那一刻没有工作区上下文，`bot_channel` 的 RLS 把行全藏起来，一行都查不到， 于是"页面上显示已连接，实际上没人在拉消息"。 - 迁移 0016 补一条只读策略：`current_setting('app.bot_list') = 'on'` 时允许 SELECT （只开 SELECT，防止顺手拿它改别人的通道）； - `start_all()` 走 `active_channel_ids()`，先设这个 GUC 再列通道； - 补测试 `test_startup_sees_logged_in_channels`。	2026-11-05 23:33:44 +08:00
Steven	07b01db7cc	fix(integrations): 一个通道只让一个进程收消息，gunicorn 双进程不再抢同一条会话 ... 生产是 `gunicorn -w 2`，两个进程各自跑 lifespan，start_all() 会把同一个通道的 长轮询拉两遍：消息被其中一个消费、回复从另一个发出，游标还会互相覆盖。 改成 Postgres 会话级 advisory lock 做租约：抢到的进程收消息，另一个每 10 秒重试， 主进程一挂连接断、锁释放，备用进程立刻接上。页面上的"接收中"只认抢到租约的那个 （`manager.polling()`），不再把等锁的也算进去。 补测试 `test_only_one_process_holds_the_polling_lease`： 第一个抢到、第二个抢不到、第一个放手后第三个能接上。	2026-11-05 23:28:35 +08:00
Steven	8436c0edbf	feat(integrations): 微信要先扫码配对，改成 iLink 扫码登录 + 长轮询 ... 上一版按"webhook + URL 里带令牌"自己编了一套，用户当场指出微信必须先扫码配对。 现在照腾讯 iLink Bot 协议自己做客户端：取二维码 → 手机扫码确认 → 存加密登录态 → 后端长轮询收消息 → 用 context_token 回话。独立实现，不依赖 DSH 的运行环境。 后端 - wechat_ilink.py：get_bot_qrcode / get_qrcode_status / getupdates / sendmessage， bot_token 用 Fernet（密钥由 JWT_SECRET 派生）加密入库，日志与接口都不回明文 - wechat_intake.py：一句话 → 任务或知识草稿，前缀识别、#标签、首行标题 - wechat_bot.py：每条通道一个轮询任务，启动时按 status='active' 恢复； message_id 去重；errcode -14 转 expired 让用户重新扫 - api/integrations.py 重写成扫码三接口 + 停用/断开/最近消息 - 迁移 0013（登录态列）、0014（轮询入口按 app.bot_channel 主键的 RLS 口子） Web - 接入页改成扫码流程：页面里画出二维码、每 2 秒问一次状态、连上显示微信用户与最近消息 验证 - pytest 149 passed（新增 test_wechat_bot 9 例） - ruff check / ruff format --check 干净；tsc 0；vite build ✓ - web/e2e/integrations.mjs 7 项 ALL PASS（拿的是微信真二维码） 教训：接入第三方协议先去已有实现里找协议，别从直觉倒推。	2026-11-05 23:03:18 +08:00