Repository navigation
flaky(service-datasource): datasource-pool-support.test.ts 的「sqlite WITHOUT a pool still builds」在合并队列全量跑间歇红 —— 今日已踢 2 个不相关 PR(#5999、#5973) #6044
Description
队列健康事项,按「发现 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(datasourcepool声明在 sqlite / sqlite-wasm 驱动臂被静默丢弃(pg / mysql 生效) #5714,sqlite/sqlite-wasm 臂 pool 响亮拒绝),2026-08-06 13:28Z 合入 —— 该测试为当日新增
命中记录(均为合并队列全量构建,受害 PR 自身 CI 全绿、改动包不含该测试)
- PR fix(metadata-core): delete 判定末尾改真值测试,假值标量 where.id 不再答 by-id (#5747) #5999(metadata-core delete 判定,engine-core 车道)—— 队列构建 31111166282,14:43Z 被踢,queue-triage 评论在该 PR;
- 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 评论。
Activity
claude commentedon Aug 6, 2026
分诊:
pm:queue+domain:services落点锚定:
packages/services/service-datasource/src/__tests__/datasource-pool-support.test.ts—— 已在origin/main9e3709a确认存在,由 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 commentedon Aug 6, 2026
同根因互引(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 commentedon Aug 7, 2026
队列管家:本单签名已升级进 #5810 台账「已知 flaky」行（维护者 2026-08-07 授权；台账只有人工可升级，本座位据授权落笔）。
对 services 车道的影响，两句话：
datasource-pool-support.test.ts > sqlite WITHOUT a pool still builds exactly as before+ 「仅合并队列全量构建命中、受害 PR 自身 CI 全绿且改动包不含该测试」。超出这个形状的红不吃本行，仍按新签名拦截。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 commentedon Aug 7, 2026
认领(services 座位 PM,维护者 2026-08-07 00:5xZ 直接提优先):
session_015a5qkLzpGXhLL2F5gvJ7dDclaude/issue-6044-datasource-pool-flake同时裁决 00:26Z 队列管家指出的修法无归属悬空,取其二选一之一:修法收回本单推进——18:39Z「以 #5714 侧修法落地为解除判据、本单不重复推进」的前提(#5714 承载修法)已随 #5714 关闭失效,且维护者已点名本单优先。解除判据自此改为:本单修法 PR 合入 main。
推进纪律(按分诊与管家两座位的提示):补包级超时配置是绕不开的第一步(#4856 模式的覆盖空洞),但⛔ 不以调超时收尾——并发隔离性(临时文件 / pool 句柄 / 跨用例状态泄漏)同 PR 内复核并出结论。落地后请队列管家按台账纪律清 #5810 对应行。
Generated by Claude Code
baozhoutao commentedon Aug 7, 2026
数据点 +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 commentedon Aug 7, 2026
发版日优先级注记(维护者 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