From dc064f40b86e56e3577654e833d2977aae265a93 Mon Sep 17 00:00:00 2001 From: JianFeeeee Date: Mon, 21 Sep 2026 07:29:33 +0800 Subject: [PATCH] =?UTF-8?q?=E9=87=8F:=20=E9=82=A3=E4=B8=AA"=E5=B0=91?= =?UTF-8?q?=E6=A0=87=E6=9C=AB=E4=BD=8D"=E7=9A=84=20bug=20**=E4=BB=8D?= =?UTF-8?q?=E5=9C=A8=E7=94=9F=E4=BA=A7=E6=B4=BB=E7=9D=80**=20=E2=80=94?= =?UTF-8?q?=E2=80=94=2013=20=E6=AC=A1=E8=B0=83=E7=94=A8=2013=20=E6=AC=A1?= =?UTF-8?q?=E6=BC=8F=E6=9C=AB=E4=BD=8D=EF=BC=8C=E4=B8=94=E5=AE=83=E8=87=AA?= =?UTF-8?q?=E5=B7=B1=E5=88=B6=E9=80=A0=E9=87=8D=E6=8A=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 顺着 pi 的 `4→8→2` 追下去时，把本会话日志里**每一条会标已读的** `read_inbox` （`status != 'all'`；`all` 按 `idsToMarkRead` 定义**故意不标**）与 `mail_reads` 的 **同 `read_at` 串**批次对齐，得到比原先 3 行更完整、也更硬的一组读数： 13 次调用 → 列出 81 封 / 同批标上 68 封 ⇒ **少 13 封** 漏的**永远是列出的最后一个**，13/13，零例外 （原本 docs 里只有 04:10/04:33/06:00 三次；现在补到 13 次，跨 09-18~09-21。） ## 一、★ 它仍在生产活着：修复没部署 `17908c1`（04:25:17）修的就是这个。但线上二进制 **mtime = 09-19 13:04**、进程启于 09-20 04:01 ⇒ **跑的还是旧代码**。09-21 的 5 次里**有 4 次在提交之后**，症状照旧。 ⇒ **"修好了" ≠ "生效了"。**（04:10:57 那次在提交**之前**，不能当反例 —— 我初稿写成 "5 次全在提交之后"，复核时自己抓到。） ## 二、★★ 这个 bug 会**自己制造重投**（因果链，9/12 直接命中） 漏标的末位**仍算未读** ⇒ **紧接着的下一次 `read_inbox` 又把它列出来**： 09-18 04:43 漏 2800c865 ⇒ 04:55 又列出 ✓ …（共 9 条直接命中） 其余 3 次因换会话/中断未在紧邻调用里复发 本会话日志里同一封被重复列出过的共 **27 封**，其中 **12 封**正属于"被漏标"这批。 ⇒ **重投不是另一个 bug，它就是漏标的直接后果。** （这也回过头解释了 pi 观测到的 `4→8→2`：**收缩**来自 read_inbox 批量扫走， 而**膨胀**里有一部分是我上一轮漏标留下的。） ## 三、★ 我的读数方法自己纠正过我一次 第一版用"秒级窗口"匹配 ⇒ 得到 12 次漏末位 + **1 次"全标上"的假例外**。 改用**同 `read_at` 串**（一次 `POST` 的所有插入共享同一条 `strftime(...,'now')`） ⇒ 例外消失、**13/13 全部漏末位**。 ⇒ **读数方法不严，会把一个完美一致的信号读成一个有噪声的信号** —— 而"有噪声"会让人放弃追查。我又差点因此把 13/13 记成 12/13。 ## 四、顺带的算术自洽 表内 `列出 81 − 标上 68 = 13 = 漏标次数`（每次恰漏 1 封）—— 与"总数守恒"同族的免费交叉验证。 --- docs/API.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/docs/API.md b/docs/API.md index 196e6d8..2c5b002 100644 --- a/docs/API.md +++ b/docs/API.md @@ -471,15 +471,57 @@ curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY" 因为**线上跑的还是有 bug 的二进制**（构建于 09-19 13:04，早于 `f2063e1`）。 形态与离线探针**逐字一致**——`read_inbox` 列 N 封、**只标上 N-1 封，漏的永远是末位**： - | 调用 | 列出 | 同刻标上 | 末位 | + | 调用(HKT) | 列出 | 同批标上 | 漏的末位 | |---|---|---|---| - | 04:10:57 | 5 | 4 | `474323c3` 漏 | - | 04:33:34 | 5 | 4 | `1494154f` 漏 | - | 06:00:46 | 10 | 9 | `c416c98e` 漏 | + | 09-18 04:43:05 | 3 | 2 | `2800c865` | + | 09-18 04:55:20 | 10 | 9 | `4f702d7c` | + | 09-18 05:06:56 | 6 | 5 | `85586f9b` | + | 09-18 05:07:14 | 11 | 10 | `bc6817c9` | + | 09-18 07:43:25 | 3 | 2 | `63ff976a` | + | 09-19 12:43:03 | 5 | 4 | `70ad57d3` | + | 09-19 12:57:15 | 3 | 2 | `63ff976a` | + | 09-20 04:06:28 | 10 | 9 | `fe9b830c` | + | 09-21 04:10:57 | 5 | 4 | `474323c3` | + | 09-21 04:33:34 | 5 | 4 | `1494154f` | + | 09-21 06:00:46 | 10 | 9 | `c416c98e` | + | 09-21 06:39:22 | 6 | 5 | `e427d928` | + | 09-21 07:02:20 | 4 | 3 | `5ff4318c` | + | **合计** | **81** | **68** | **少 13** | + + **口径**：只取 `status != 'all'` 的调用（`all` 按 `idsToMarkRead` 的定义**故意不标**）； + "同批"= `mail_reads` 里 `read_at` **字符串完全相同**的那一组 + （一次 `POST` 的所有插入共享同一条 `strftime(...,'now')`）。 + **13 次调用、13 次漏末位，零例外。** + + ⚠️ **09-21 那 5 次里有 4 次（04:33 起）发生在 `f2063e1` 提交（04:25:17）之后**， + 但因**没有部署**，症状照旧 ⇒ **"修好了"与"生效了"是两件事**。 + （另：04:10:57 那次在提交**之前**，本来就不该指望它修好 —— 不能拿来当反例。） + + ★ 这套对齐**自己纠正过我一次**：我第一版用"秒级窗口"匹配， + 得到 12 次漏末位 + 1 次"全标上"的**假例外**；改用**同 `read_at` 串**后例外消失、 + **13/13 全部漏末位**。⇒ **读数方法不严，会把一个一致信号读成有噪声的信号。** **跨调用同信同位对照**（最强的一档）：`474323c3` 在 04:10:57 排**末位 ⇒ 漏**， 在 04:33:34 排**第 2 位 ⇒ 标上**。同一封信、只换位置、结果相反 —— 因果钉在**批次位置**上。 + ★★ **这个 bug 会自己制造"重投"（因果链，实测 9/12 直接命中）**： + 漏标的末位**仍算未读** ⇒ **紧接着的下一次 `read_inbox` 又把它列出来**： + + ``` + 09-18 04:43 漏 2800c865 ⇒ 09-18 04:55 又列出 ✓ + 09-18 04:55 漏 4f702d7c ⇒ 09-18 05:06 又列出 ✓ + 09-18 05:06 漏 85586f9b ⇒ 09-18 05:07 又列出 ✓ + 09-19 12:43 漏 70ad57d3 ⇒ 09-19 12:57 又列出 ✓ + 09-19 12:57 漏 63ff976a ⇒ 09-20 04:06 又列出 ✓ + 09-21 04:10 漏 474323c3 ⇒ 09-21 04:33 又列出 ✓ + 09-21 04:33 漏 1494154f ⇒ 09-21 06:00 又列出 ✓ + 09-21 06:00 漏 c416c98e ⇒ 09-21 06:39 又列出 ✓ + 09-21 06:39 漏 e427d928 ⇒ 09-21 07:02 又列出 ✓ + （其余 3 次因换会话/中断未在紧邻调用里复发） + ``` + ⇒ 本会话日志里同一封被重复列出过的共 **27 封**，其中 **12 封**属于"被漏标"这批 + ⇒ **重投不是另一个 bug，它就是漏标的直接后果。** + ⚠️ **由此得到一条容易看错的教训：缺口是"流量"不是"库存"。** 回填前的缺口**两次独立测量都是 40 行**（pi 04:43 HKT 量到 40，分布 dsh10/pi21/zcode5/ homeagent3/jianf1；我 06:03 量到 40，分布相同），看着像个稳定常数，