1. 13 Oct, 2026 8 commits
  2. 12 Oct, 2026 2 commits
  3. 10 Oct, 2026 12 commits
  4. 09 Oct, 2026 8 commits
  5. 08 Oct, 2026 4 commits
  6. 06 Oct, 2026 2 commits
  7. 21 Sep, 2026 2 commits
    • fix(plan): 确认分配 500 —— 全 null 数组被 Prisma 推成 integer[],撞上 ::timestamptz[] · 5fcd4afe
      FRIDAY 宿主接入测试机后,点「确认分配」必 500:
        POST /pac/v1/plans/assignments → 42846
        cannot cast type integer[] to timestamp with time zone[]
        at plan-assignment.service.ts:392 ($transaction 内)
      
      机理:Prisma 从**值**推断数组元素类型。`aDedicatedCsLastVisit`(该患者专属客服的
      最近到诊时间)整个数组非空且全是 null 时推不出来,退化成 integer[],撞上显式
      ::timestamptz[]。⚠️ 空数组 [] 反而安全(走不到转换),**只有「非空且全 null」才炸**。
      
      为什么瑞尔一直没事:那边有回访历史,多数患者有专属客服 → 数组里总有非 null。
      FRIDAY 是新宿主、无回访历史 → 整批全 null。
      ⇒ **这不是 FRIDAY 特有的**,瑞尔只要碰上「这批人恰好都没有专属客服」一样炸。
      
      修法:参数以 ISO 文本传,再整体 ::text[]::timestamptz[]。三种形态(全 null /
      混合 / 全有值)都在测试机实测通过。不动 t(...) 的列名与顺序 —— 九个数组的位置
      对应关系很脆,那里原本就有一条警告。
      
      实测哪些目标类型会塌(2026-09-21 测试机):
        ::timestamptz[] ❌  ::uuid[] ❌
        ::text[] ✅  ::double precision[] ✅  ::int[] ✅
      ⇒ 同段的 aDedicatedCs(::text[])、aSourceConfidence(::double precision[])
        虽然也可空但**没病**,没有顺手改 —— 测试里专门锁了这一点。
      
      测试:新增仓库级守卫 —— 凡 ${x}::timestamptz[] / ::uuid[] 且 x 声明含 `| null`
      即判失败,覆盖全 src 而不只是这一处。5 项变异全部被咬红,其中一项
      (toContain('toISOString()'))第一版没牙、被变异测试当场抓到后已收紧为只锁那一行。
      全量 1979 passed。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
  8. 05 Sep, 2026 2 commits
    • docs(ops): 更正余量口径 —— 我之前报的 36%/2.8倍 是错的,cgroup 实测 58%/1.7倍 · af0db174
      量错了指标。mem_limit 管的是 cgroup 的 memory.current,而我拿 `docker stats`
      和进程 rss 当依据,三者差 1.6 倍:
      
        cgroup memory.peak = 4760 MiB   ← mem_limit 真正管的数(58% of 8192)
        docker stats 采样  = 3.53 GiB   ← 采样,峰值漏在间隔里(我 10 分钟一采)
        进程 rss 峰        = 2936 MB    ← 不含 page cache
      
      差额是 page cache + 堆外分配。8g 仍然站得住(且 4760 里相当部分是可回收的
      page cache —— 跑完后 file 段只剩 2 MiB),但余量是 1.7 倍不是 2.8 倍。
      正确量法写进注释:`cat /sys/fs/cgroup/memory.peak`,并注明高水位随容器重建清零。
      
      同时这个数推翻了「堆上限 6144 ⇒ V8 一定先抛」的说法:cgroup 高水位比堆峰值
      多出约 2.2G,堆若真涨到 6144,总量会逼近 8192,谁先触发取决于当时可回收的
      page cache 有多少。改成如实写"大概率而非硬保证",并给出想要硬保证时该取的
      值(5120)和它的代价。6144 保持不变。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed