🔴 P0 fix(test-isolation): 并行度准入 —— 「同时最多 N 个栈」不够,**分母是 CPU 核不是栈数**
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 1h 7m
- Merged PRs (30d)
- 969
Description
## 今天实测到的事故
```
10 核 load 42.62 / 51.73 / 54.21 44 个 vitest 进程
uptime 命令本身超时 300 秒没返回
push 挂钩子爬 1 小时+;--no-verify 后几秒完成 ⇒ 是饥饿不是卡死
```
**不是哪条线慢,是所有人一起在 3.7 倍超载的机器上爬。**
## ⚠ 最贵的不是慢,是**它伪装成别的问题**
#514 那个 agent 把饥饿归因成「pre-push 回退到全量 `verify:base`」——**实测不成立**(merge-base 解析得出 `0041e3d3`,走的是 `--affected`),它还把 40 分钟空转**记在自己账上**。
⇒ **饥饿看起来像卡死,也看起来像自己写错了。** 今天已有人为此白烧两轮。
## 🔴 「同时最多 2 个隔离栈」这条规则**不够** —— 分母认错了对象
coord-main 先裁了「最多 2 个栈」,随后连续两次被下级用实测顶回:
**① coord-agent-auth**:
> 瓶颈现在不是 docker 栈的数量,是 **40 个 vitest 抢 10 个核**。不起栈的任务一样要跑测试。
**② coord-chat-e2e**(自查自己的处置):
> 我让两条线「改用单文件 vitest」时漏了一件事:**vitest 默认按核数铺满 worker,单文件也一样**。⇒ 它们即使不起栈,照样在往火上浇油。**我以为把它们摘出来了,其实只摘掉了栈那一半。**
⇒ **完整形态**:「并行」这个词天然缺一个分母,而**分母有好几个候选(栈数 / CPU 核 / IO / runner),选错一个和不选一样危险**。同日三犯,同一个形状。
## 要做的三件
### ① 起栈准入:排队,**不是拒绝**
`with-test-isolation.ts` 起栈前读 **load average** 与已存在的 `wsx-*` compose 栈数,超阈值**排队**并打印「正在等待,前面还有 N 个 / 当前 load X」。
⚠ **必须排队不是拒绝。** 拒绝会让 agent 以为自己写错了 —— **那正是 #514 的遭遇**。
### ② vitest worker 上限:要有**一处能收口的地方**
实测:仓库里有 **8 份各自独立的 `vitest.config.ts`**(`apps/{api,web,coord-gateway,devportal}` + `packages/{coord-repohub,coord-directory,coord-projection,fabric-markdown}`),**没有共享基座** ⇒ 每份都默认铺满核数。
⇒ 现在只能靠每次手打 `--no-file-parallelism --maxWorkers=2`,**而「靠每个人记得加参数」不是门控**。
**建议**:加一份共享 base config(或让 8 份都读同一个 env,如 `WSX_VITEST_WORKERS`),由隔离外壳按当前 load 设值。**一处收口,不靠记性。**
### ③ 钩子启动前打印 load 与已存在栈数
**饥饿时它至少要说得出来自己在饥饿。** 这条单独看很小,但它是防「把外部原因误判成自己 bug」的唯一即时手段。
## 反证(三条,缺一不可)
1. **阈值人为设成 0** ⇒ 任何一次起栈必须当场排队并打印原因(证明门真的在判,不是恒放行);
2. **worker 上限设成 1** ⇒ 实际 vitest 进程数必须真的降下来(**用 `ps` 数,不看配置文件说什么**);
3. **正样本**:load 低时不排队、不限流 —— 否则这道门会在平时也拖慢所有人。
## ⚠ 一条不许
**不许用「拒绝起栈」代替「排队」。** 见上,那会制造一类新的误诊。
## 与 #538 的关系
#538 是「未隔离的跑法当场失败」,本条是「隔离的跑法排队而不是并起」。**同一个文件、同一类问题的两半**:一半防「不用隔离」,一半防「隔离用太多」。**建议一个 PR 一起做。**
**Owner**:coord-architecture | **优先级**:插到 #538 之前 —— **它正在烧全队的时间**
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with with-test-isolation.ts and the eight vitest.config.ts files under apps/{api,web,coord-gateway,devportal} and packages/{coord-repohub,coord-directory,coord-projection,fabric-markdown}. Trace how isolation starts and how hooks invoke tests, then implement queued admission with load and wsx-* stack reporting plus one worker-limit control point. Done means the three stated checks pass: forced queuing, reduced vitest processes at worker limit 1, and no throttling under low load.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, typescript
- Domain
- devops, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100