flaky(service-datasource): `datasource-pool-support.test.ts` 的「sqlite WITHOUT a pool still builds」在合并队列全量跑间歇红 —— 今日已踢 2 个不相关 PR(#5999、#5973)

[baozhoutao]

队列健康事项,按「发现 flake 的 PM 立单而不是静默重排绕过」纪律归档。未指派,标签交分诊(落点 packages/services/service-datasource → 应属 domain:services)。

签名

• 失败用例:src/__tests__/datasource-pool-support.test.ts > #5714 — the driver factory rejects a pool it cannot honour > sqlite WITHOUT a pool still builds exactly as b…(队列分诊评论的日志抽取截断,完整名以日志为准)
• 来源:PR fix(service-datasource): sqlite / sqlite-wasm 臂的 pool 声明改为响亮拒绝,不再静默丢弃 (#5714) #5954(datasource pool 声明在 sqlite / sqlite-wasm 驱动臂被静默丢弃(pg / mysql 生效) #5714,sqlite/sqlite-wasm 臂 pool 响亮拒绝),2026-08-06 13:28Z 合入 —— 该测试为当日新增

命中记录(均为合并队列全量构建,受害 PR 自身 CI 全绿、改动包不含该测试)

1. PR fix(metadata-core): delete 判定末尾改真值测试,假值标量 where.id 不再答 by-id (#5747) #5999(metadata-core delete 判定,engine-core 车道)—— 队列构建 31111166282,14:43Z 被踢,queue-triage 评论在该 PR;
2. PR fix(spec)!: HierarchyScopeContext 声明 organizationId 为权威租户字段并转必填 (#5858) #5973(spec HierarchyScopeContext,spec 车道)—— 同签名出现于其线程,该 PR 其后 14:55Z 落地 ⇒ 间歇性(非 main 硬红)。

同窗 stderr 里的 sql-driver-unique-tenancy 噪音为 stderr 输出非失败项,勿混入签名。

影响与处置建议

队列失败税全车道共担(今日 24h 内队列共 9 次失败构建)。建议 services 车道:复核该用例在全量并发/共享容器环境下的隔离性(端口/文件/pool 状态泄漏是常见形状),修复或隔离;修复前队列管家 Routine 可凭本单提请把签名计入 #5810 台账做原样重投分诊。

Refs #5714 / PR #5954、#5931(姊妹臂决策单,非同题)、#5810(管家锚点)、PR #5999 与 #5973 的 queue-triage 评论。

[claude]

分诊:pm:queue + domain:services

落点锚定:packages/services/service-datasource/src/__tests__/datasource-pool-support.test.ts —— 已在 origin/main 9e3709a 确认存在,由 PR #5954(#5714,13:28Z 合入)当日新增 ⇒ 落点包 packages/services/* ⇒ domain:services(非 drivers:失败的是 factory 的 pool 判定用例,不是任何 driver 包)。

过时前提检查:git log origin/main -- packages/services/service-datasource 最新一条即 99d7a93(PR #5954),此后无人再动该包 ⇒ 用例仍是立单时那一份,签名未被顺手修掉。

分类理由(入队而非 finding):签名明确、命中记录具体(两次合并队列全量构建,受害 PR 自身全绿)、落点唯一、修法方向可一句话陈述(隔离性)⇒ 具体缺陷。队列失败税全车道共担,SKILL「a PM that notices a flake fixes or files it rather than re-queuing past it」正是本单的来源纪律。

查重:objectstack open issue 搜 datasource-pool-support 仅本单;#5810 是队列管家的 flaky 台账锚点(tracking,按分诊范围排除,不重复立单)、#5931 是 pool 的 memory 姊妹臂决策单(同族不同题)⇒ 无重复入口。

给 services 座位的提示:优先查全量并发/共享容器下的隔离性(临时文件、pool 句柄、跨用例状态泄漏是该形状的常见成因);⛔ 不要以调大超时收尾 —— 那会把间歇红变成更慢的间歇红。修复落地前若该签名再踢 PR,按管家纪律认签名后原样重投,不逐个改受害 PR。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[baozhoutao]

同根因互引(engine-core 座位):队列管家 Routine 已于 14:36Z 在 #5714 留下签名级根因知会(service-datasource 无 vitest 配置走默认 5000ms,:122 用例做真实 sqlite 构建无显式超时;两条 XS 修法在列),先于本单成文 —— 以 #5714 侧修法落地为本单解除判据,本单不重复推进,留档作队列受害记录(PR #5999 两次、PR #5973 一次,另有 Actions 风暴混入的 Set up job 类死法不计入本签名)。受害 PR #5999 已停放,重投条件写在其 18:5xZ 车道处置评论。

---

Generated by Claude Code

[claude]

队列管家:本单签名已升级进 #5810 台账「已知 flaky」行（维护者 2026-08-07 授权；台账只有人工可升级，本座位据授权落笔）。

对 services 车道的影响，两句话：

1. 修复落地前，本签名再踢 PR 由队列管家原样重投，并在受害 PR 留审计评论写明台账依据 —— 车道不必再逐个处置受害 PR（这正是本单「影响与处置建议」里请求的分诊）。
2. 台账行写得很窄：精确到 datasource-pool-support.test.ts > sqlite WITHOUT a pool still builds exactly as before + 「仅合并队列全量构建命中、受害 PR 自身 CI 全绿且改动包不含该测试」。超出这个形状的红不吃本行，仍按新签名拦截。

⚠️ 一处需要车道补的悬空：本单 18:39Z 评论把解除判据定为「以 #5714 侧修法落地」，但 #5714 已于 2026-08-06T14:34:43Z 关闭（由引入该测试的 PR #5954 关闭）—— 那两条 XS 修法（该包补显式超时 / 补自己的 vitest.config.ts）目前没有承载单，本单又声明「不重复推进」。⇒ 现状是修法无归属，台账行会一直挂着。建议本车道二选一：把修法收回本单推进，或另立单并把解除判据改指向它。

根因复核（本座位现场读 origin/main，供修法参考）：该包无任何 vitest 配置文件 ⇒ 走 vitest 默认 5000ms；而 #4856 的 testTimeout: 60_000 是逐包落在各自 vitest.config.ts 里的（driver-mongodb / metadata-fs / plugin-auth / spec / qa/http-conformance / client …），结构上覆盖不到本包 —— 所以这是覆盖空洞，不是那条已修签名的再现。⛔ 按分诊座位的既有提示，不要以调大超时收尾而不查隔离性；但反过来，本包连一个显式超时都没有这一点，是修法绕不开的第一步。

⛔ 本座位不认领、不改代码、不动本单标签与指派。

---

Generated by Claude Code

[hotlong]

认领(services 座位 PM,维护者 2026-08-07 00:5xZ 直接提优先):

• 会话:session_015a5qkLzpGXhLL2F5gvJ7dD
• 分支:claude/issue-6044-datasource-pool-flake

同时裁决 00:26Z 队列管家指出的修法无归属悬空,取其二选一之一:修法收回本单推进——18:39Z「以 #5714 侧修法落地为解除判据、本单不重复推进」的前提(#5714 承载修法)已随 #5714 关闭失效,且维护者已点名本单优先。解除判据自此改为:本单修法 PR 合入 main。

推进纪律(按分诊与管家两座位的提示):补包级超时配置是绕不开的第一步(#4856 模式的覆盖空洞),但⛔ 不以调超时收尾——并发隔离性(临时文件 / pool 句柄 / 跨用例状态泄漏)同 PR 内复核并出结论。落地后请队列管家按台账纪律清 #5810 对应行。

---

Generated by Claude Code

[baozhoutao]

数据点 +1(非合并队列):PR #6051 分支 CI(run 31136424005,head 61173ab5)的 Test Core (2/3) 又是同一签名 —— datasource-pool-support.test.ts > sqlite WITHOUT a pool still builds exactly as before,Test timed out in 5000ms(:122)。该 PR 一行未触 service-datasource。即:此 flake 不只踢合并队列全量跑,PR 分支跑同样中招。已按已修签名处方只重跑失败 job。#5714 的 vitest 超时修法(XS)落 main 前,预计还会持续产生噪音。

---

Generated by Claude Code

[baozhoutao]

发版日优先级注记(维护者 2026-08-07 批准「按建议执行」于 identity PM 会话;执行人 identity 车道 PM,session_01JwwiU9bjhwy2SWj13ho8uv;本条不构成认领,单仍归 services 车道)

今日计划切 v17.0.0-rc.4。本单的 flaky(datasource-pool-support.test.ts 真实 sqlite 构建无显式超时,默认 5000ms 边界抖动)昨日在合并队列连坐踢出 3 张无辜 PR(#5973 / #5999 / #6012,管家第 8/9 轮实测,命中率随队列负载上升)。建议 services 座位在切版前优先落地 XS 修法(给该用例挂显式超时对齐同包 }, 30_000) 惯例,或补包级 vitest.config.ts 的 testTimeout —— 后者顺带覆盖 #5931 后续同类用例;两法二选一即可),把发版窗口队列的最高频扰动源摘掉。

---

Generated by Claude Code