boardx / boardx/workspacex

flake: agui-bridge 测试的固定 30s 预算在满载 shard 上先倒,已两次伪装成 PR 回归

Open
#2,968 5 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
1h 7m
Merged PRs (30d)
969

Description

## 现象

`apps/api/tests/agent-runtime/agui-bridge-*.test.ts` 里的用例都写死 `30_000` 超时。在满载 shard 上它们会 `Test timed out in 30000ms`,而**同一个 SHA 重跑就绿**——也就是说这个红跟被测改动无关,但它出现在 PR 上时看起来完全像是这个 PR 的回归。

今天一天之内已经骗到两个互不相关的 PR:

| PR | 失败 job | 失败用例 | 旁证 |
|---|---|---|---|
| #2947(Office skills) | `gates-test (1)` | `agui-bridge-sse.test.ts` → `DA-19a: reusing the CUSTOM-reported chat_thread_id ... continues the SAME Chat thread` | GitHub 在**同一个 SHA** `4355a7bd1` 上重跑 attempt 2,通过 |
| #2962(durable subtask artifacts) | `gates-test (3)` | `agui-bridge-state-events.test.ts` → `write_todos 的 toolArgsSummary 被 4000 字符截断成坏 JSON → 零 STATE_* 事件` | 该 shard `Duration 517.46s`(tests 422s),1 failed / 1874 passed |

两个 PR 的 diff 都不碰 AG-UI bridge。#2962 因此被交接文档记为「红灯待修」,实际上很可能根本没有需要修的东西——已在 [run 34135295245](https://github.com/boardx/workspacex/actions/runs/34135295245) 上重跑同 SHA 取证。

## 为什么是这几个用例先倒

`30_000` 是**平铺**的,不按用例实际工作量分配。而这些用例里最慢的那些各自要做**两趟完整的 durable bridge 轮次**(每趟一次真实 HTTP 往返 + 服务端轮询到终态),单趟余量只有同文件里单轮次兄弟用例的一半。shard 一旦被别的重测试拖慢,它们就是最先撞线的。

`agui-bridge-state-events.test.ts` 里那条截断用例同理:它要跑满 provider 的 4000 字符截断路径,`content` 是 `"长".repeat(5000)`。

## 这不是「把超时调大」这么简单

调大数字能止血,但会掩盖真实的性能回归——本仓已经有「门控全绿但空转」的历史。建议的判据:

1. 先确认这是**排队/负载**导致,而不是这些用例本身在最近变慢了:对比同一用例在空闲 shard 与满载 shard 上的实际耗时。
2. 如果确实是负载,超时应当从「固定值」改成「与该用例的轮次数成比例」,并在注释里写清这个数字是怎么来的——而不是又一个拍脑袋的常数。
3. 顺带评估这些 bridge 用例是否该从 `gates-test` 的通用 shard 里挪出去,避免它们和重 DB 测试抢同一个预算。

## 影响

在修掉之前,任何 PR 上出现 `agui-bridge-*` 的 30s 超时都应先**同 SHA 重跑**判定,再决定是不是自己的回归。今天已经有一份交接文档因为没做这一步而把结论写错。

⚠ 不要把这条当成「重跑就好」的许可:真实回归同样会以超时形态出现,重跑绿才是判据,不是重跑本身。

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with apps/api/tests/agent-runtime/agui-bridge-*.test.ts, especially agui-bridge-sse.test.ts and agui-bridge-state-events.test.ts, and compare their timing on idle versus full shards. Re-run the cited SHA when validating the flake. Done means establishing whether load causes the failures, replacing fixed budgets with documented per-round limits if appropriate, and assessing whether these tests should leave the gates-test shards.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, typescript
Domain
ci-cd, performance, testing
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.