Prod 实锤 —— 同一个人,因为一个空格,在系统里是两个人:
| 在收消息的名单里 | 在组织成员名单里 |
|---|---|
Alex (彦序) ← 有空格 | Alex(彦序) ← 没空格 |
傅丰凯 | 付丰恺 |
所以才需要 recipient-aliases.json 人肉打补丁 ——
而补丁永远追不上。
和 7 月客户那边是同一个病。アトレ / アトレ_GBaseSupport 名字漂移 →
pipeline fail-close → 最后靠 migration 0039 改成用 customers.id。
客户那边已经付过代价改成 id 了,人这边还在用名字。
20 个正式成员收不到任何消息(你自己也在这份名单里)。
同时 傅丰凯(MiniBee 的开发)在收销售消息。
47 不是销售人数,是历史堆积 ——
里面有 Admin、开发、测试号。28 才是真的。
| 决定 | |
|---|---|
不建 user_channels 表 | 渠道绑定就是 runs_users 上的两列。多一张表 = 多一处会漂移的地方 |
notify 放 runs.db | 盒子级偏好 —— 同一个人在 A 组织要收、B 组织不要收,是合理的 |
sales_owner_id 是 FK | 现在 profile.md 里存的是名字。这就是 #201 那个病 |
| 步 | 做什么 | 效果 |
|---|---|---|
| 1 | notify 挪进 DB,只给那 28 人按 name + display_names 匹配一次,匹配不上的**列出来人工过**,不静默跳过 |
立刻修好「20 人收不到」 顺带把 4 个非成员摘掉 |
| 2 | 收件人解析改用 user_id纯函数层 worker/lib/org_members.py,和 mail_query.py 同形 |
根治。名字只用来显示,不再当外键 |
| 3 | 废弃 config.yaml team.members + org-members.json先停止读,观察两周再删 |
四份 → 一份 |
| 4 | Mio 的花名册改走 MCP list_org_members |
JSON 退役后 Mio 不会拿着死指针 |
⚠️ prod 新盒子(spt-fde)根本没有 config.yaml / org-members.json ——
新架构其实已经不生成它们了,只是老盒子还留着。这佐证了「废弃」而不是「合并」。
绕开第 0 步先做后面任何一条,产出的都是建在名字匹配上的第五份名单。
20 个人收不到消息,是此刻正在发生的事,不是设计问题。
| 选项 | |
|---|---|
| 先单独修这一条 手工把 28 人补进 config.yaml 的 notify |
半小时,立刻止血。但那是往要废弃的文件里加东西 —— 做完还得再迁一次 |
| 直接做第 1 步 | 一两天,做完就是终局。但这一两天里那 20 人继续收不到 |
我倾向直接做第 1 步 —— 这个状态已经存在了一段时间(config.yaml 是 5 月的),
再多一两天不改变性质;而往废弃文件里加东西,是在给自己造第二次迁移。
但如果你觉得这两天有要紧的通知会漏,那就先止血。你拍。