flaky: plugin-audit zh-CN 摘要与 cloud-connection marketplace seed 在整仓并发下偶发失败(单跑必过)

[os-zhuang]

#3723 / PR #3747 期间两轮整仓 npx turbo test 各偶发失败不同的包,单独重跑及干净工作树上均通过。记录下来,免得下一个 agent 重新排查一遍 —— 我为排除自己的改动做了两轮 stash 对照才确认无关。

✅ 已解决（2026-07-30）：两半都已定位根因并修复 —— plugin-audit 见 PR #4193，cloud-connection 见 PR #4217。结论见下方评论；两者是同一症状、不同根因。

观测(2026-07-28,worktree 基于 #3747 分支,改动不涉及这两个包)

第一轮(turbo test,99 任务):

FAIL src/audit-writers.test.ts > audit writers — localized activity summaries (framework#3039)
     > localizes verb + object label to the workspace locale (zh-CN)
@objectstack/plugin-audit: Tests 1 failed | 45 passed (46)

第二轮(turbo test --continue,132 任务)—— plugin-audit 这轮通过,换 cloud-connection 挂:

FAIL src/marketplace-install-local-seed-lookup.test.ts > marketplace install — seed lookup resolution
     > writes target record ids (never raw externalId strings) for package objects unknown to the metadata service
FAIL src/marketplace-install-local-state-machine-exempt.test.ts > marketplace install — state_machine initialStates exemption (#3433)
     > lands every mid-lifecycle seed row (no initialStates rejection on the marketplace seam)
@objectstack/cloud-connection: Tests 2 failed | 62 passed (64)

对照:

• turbo test --filter=@objectstack/plugin-audit --force → 46/46 通过
• turbo test --filter=@objectstack/cloud-connection --force → 64/64 通过
• git stash -u 后干净树上两包同跑 → 全过

归类

与 #3060 / #3662 同一类:仅在整仓满并行负载下出现,单包必绿。两处都是会启动真实 kernel 的重型测试,疑似负载下的时序/资源争用,但未定位根因 —— 本 issue 首先是记录,其次才是修复请求。

失败断言本身值得看一眼的线索:

• plugin-audit 那条涉及 zh-CN 本地化摘要 —— i18n bundle 的异步加载在负载下是否有竞态;
• cloud-connection 两条都在 marketplace install 的 seed 路径 —— 与 seed replay vs state_machine initialStates: mid-lifecycle fixture rows are silently rejected on INSERT (showcase kanban can never repopulate) #3433 修复的 seam 相关,失败形态是 seed 行未落全。

建议

按前例(#3662 的处理方式)排查:若是超时类,对齐兄弟用例的显式 timeout;若是真竞态,则是产品 bug 不是测试 bug,需要升级处理。

按 AGENTS.md Prime Directive #10 立此 issue;发现于 #3747 的验证过程,与该 PR 改动无关。

---

结案摘要（2026-07-30）

上面那条"建议"里的分诊二分法是对的，两半都落在超时类，但根因不同——i18n bundle 的异步加载是否有竞态这个猜测方向也对了一半：确实是异步加载，但是异步模块加载，不是数据竞态。

	plugin-audit（#4193）	cloud-connection（#4217）
冷导入位置	测试文件自己的 helper	生产代码 install handler（故意不 mock，为了让 mock 能介入）
能否根治	能 —— 提为顶层静态 import	不能 —— 动态导入是有意设计，不该为测试改产品代码
处置	20347ms → 1ms，删掉 timeout 覆盖	预算 30s → 120s，对齐兄弟用例

两处都不是竞态：断言均通过，失败形态是纯超时。整仓 pnpm test 现已 132/132、退出码 0。

一条留给后来者的经验：marketplace-install-local-seed-lookup 早在此前就已被单独修好（提到 120s 并留下"an import stall, not a hang"的诊断注释），但修复没有推广到同包的兄弟用例，于是本 issue 的另一半又挂了三个月。同类修复记得扫一遍同源用例——判据是 {不 mock 该模块} ∩ {真正走到那条路径}。

[os-zhuang]

进展：plugin-audit 那一半已定位并修复；cloud-connection 那一半今天再次复现，但已排除同一根因。

先致歉一处重复：我今天在没有先搜索的情况下开了 #4186 记录 plugin-audit 这条，实际是本 issue 的一半。#4186 已随修复关闭，后续统一在这里跟踪。

plugin-audit（已修，PR #4193）

根因不是竞态，而是一次模块冷加载被计入了单个用例的超时预算：

audit-writers.test.ts 的 makeI18n() helper 里用 await import('@objectstack/core') + await import('./translations/index.js') 懒加载。于是第一个本地化用例独自承担了整包解析 + vite transform 的冷启动成本，其余用例都跑在已预热的模块上（~1ms）。文件里原本就带着 { timeout: 20_000 } 覆盖，注释写明了这一点（当时实测冷启动约 5s）。整仓并行下十几个包的 vitest worker 争抢资源，冷启动涨过 20s，用例就红了。

本 issue 里"i18n bundle 的异步加载在负载下是否有竞态"这个猜测方向是对的——只是它是异步模块加载，不是数据竞态。

修法：两个 import 提为顶层静态。同样的工作改为在 collection 阶段发生，而 collection 不计入任何单个用例的超时。效果：

	修前	修后
该用例耗时	20347ms → 超时失败	1ms
整文件 30 用例	—	合计 172ms
整仓 pnpm test	plugin-audit 红	132/132 通过

已确认懒加载不是在规避循环依赖：plugin-audit 正常依赖 @objectstack/core，core 不反向依赖它，且本包生产源码 audit-plugin.ts 本来就静态 import 它。顶层留了注释防止改回懒加载。

顺带扫过全仓：**没有第二个测试文件同时具备"timeout 覆盖 + 动态导入"**这一组合，所以这个具体形态是孤例。

cloud-connection（仍在，根因不同）

今天整仓跑再次复现，形态与本 issue 记录一致：

× lands every mid-lifecycle seed row (no initialStates rejection on the marketplace seam)  30076ms
  Error: Test timed out in 30000ms.
@objectstack/cloud-connection: Tests 1 failed | 63 passed (64)

单独重跑 --filter=@objectstack/cloud-connection：12 文件 / 64 用例全过。

可以排除 plugin-audit 的那个根因：marketplace-install-local-state-machine-exempt.test.ts 里没有任何 await import(，所以不是冷加载被计入超时。它是真的在做重活（marketplace 安装 + 播种，启动真实 kernel），30s 预算在满并行下不够。

因此本 issue 建议里的分诊仍然适用于剩下这一半，但要先回答一个问题：这 30s 是不够（那就对齐兄弟用例调预算），还是在负载下触发了真实的时序问题（那就是产品 bug）。区分方法：把该用例的 timeout 临时调到 120s 再整仓跑——若变绿，是预算问题；若仍超时或断言失败（seed 行未落全），就是本 issue 原文担心的那个真竞态，需要升级。

我这次没有动它：它超出手头 PR（#4211 / #4187）的范围，且两种修法的含义截然不同，不该顺手拍板。

---

Generated by Claude Code

[os-zhuang]

后一半（cloud-connection）也定性了，修复在 PR #4217。本 issue 记录的两个用例至此都有了结论。

结论：预算不足，不是竞态

按本 issue 建议的分诊路径走了一遍，答案在同一个包里就有——兄弟用例早就被诊断并修好了，只是没推广过来。

marketplace-install-local-seed-lookup.test.ts 的注释原文：

Generous timeout: the install handler dynamically imports the real @objectstack/runtime (unmocked on purpose), and that cold import alone can eat several seconds on a fresh CI runner — and multiples of that under a fully parallel turbo run... 30s was observed flaking exactly that way (an import stall, not a hang)

两个用例都驱动 MarketplaceInstallLocalPlugin，其播种路径上有两处 await import('@objectstack/runtime')（recordSeedSummary 与 mergeSeedDatasetsIntoKernel）。seed-lookup 因此被提到 120s，state-machine-exempt 被落在 30s，于是继续以同样方式 flaky。

为什么恰好是本 issue 记录的这两个

flaky 集合正好等于 {不 mock runtime} ∩ {真正驱动播种}：

测试	mock runtime	驱动播种	预算
conflict、bundle	否	否 —— 走不到那两处 import	默认 5s
reseed、heal	是	是	默认 5s
seed-lookup	否	是	120s（已修）
state-machine-exempt	否	是	30s → 120s（#4217）

这解释了一个表面矛盾：conflict/bundle 同样不 mock 却用默认 5s 也不出事——因为它们根本不播种。没有第三处需要同样处理。

判定依据（含一处需要说清的局限）

• 断言通过，不是本 issue 原文担心的"seed 行未落全"那种错误数据 → 排除真竞态；
• 在产生 30076ms 失败的同一种满并行负载下，实测耗时 15696ms；
• 整仓 pnpm test：132/132、退出码 0。

⚠️ 如实说明：15.7s 低于原来的 30s，所以这一次运行即使不改也会过，单次通过不构成修复有效的证明。论据是比例——一个在负载下典型 ~15s、且已被观测到 >30s 的成本，不可能安全地住在 30s 预算里（抖动 ≥2 倍）。120s 与兄弟对齐，真正的 hang 仍会失败，只是晚一些。

与前一半的关系

两半是同一症状、不同根因，值得记一笔以免下次被误导：

	plugin-audit（#4193 已修）	cloud-connection（#4217）
冷导入位置	测试文件自己的 helper 里	生产代码的 install handler 里（故意不 mock）
因此修法	提为顶层静态 import，成本移出用例超时预算	无法提取，只能对齐预算
结果	20347ms → 1ms	预算 30s → 120s

前者能根治是因为动态导入本身没有存在理由（本包生产源码本来就静态 import 该模块，也不存在循环依赖）；后者的动态导入是有意为之的设计（延迟解析真实 runtime，让 mock 得以介入），不该为了测试速度去改产品代码。

#4217 合并后本 issue 可以关闭。

---

Generated by Claude Code