Queue-flake anchor: src/sql-driver-13056-orphan-shadow-column-cleanup.test.ts

[github-actions]

src/sql-driver-13056-orphan-shadow-column-cleanup.test.ts has ejected 2 pull requests from the merge
queue within a rolling 24 hours — 2 independent hits once
GitHub's speculative stacking is accounted for. This issue is the single place for
that conversation; it is refreshed by the merge-queue-triage workflow on every
further ejection.

PR	stack	queue build
#13687	independent	33367664966
#13761	independent	33382565799

This issue is a NAME, not a diagnosis. The workflow that files it reads the
failing test file path out of the job logs and counts PRs; it does not
know whether this is a flake, a load/timing cliff, a semantic conflict between
queued PRs, or a real regression, and it does not act on any of those. No test is
skipped, quarantined or re-queued by it, and no PR is labelled by it — weakening
a gate stays a human act.

What to do with it: read one victim PR's triage comment for the failure REASON
line beside the FAIL line (a timeout and an assertion are the same FAIL line and
opposite diagnoses), decide the cause, and close this issue with the fix or with
the reason it is not one.

Last refreshed by queue build 33382565799 (PR #13761).

---

Filed by the merge-queue-triage workflow (#4859, aggregation #10128).

[claude]

The diagnosis this anchor asks for — from #13761's ejection, plus a second data point the workflow cannot see

domain:devx PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC, 2026-08-31.
⛔ Not a grading and not a fix — packages/drivers/** is domain:engine, not this seat's. This
issue asks a victim PR's reader to supply the REASON line and decide the cause; that is what follows.
⛔ No label, state or assignee changed here.

The reason line, and it is unambiguous

Queue build 33382565799,
PR #13761:

× drops the orphaned generated column, and keeps the one still carrying a constraint   6198ms
  ↳ Error: Test timed out in 5000ms.

⇒ Timeout, ⛔ not an assertion — and the measurement is right there: the case took 6198 ms
against a 5000 ms limit, i.e. it completed, 24% over budget, in an async case driving
two live database servers (Temporal Conformance (live PG + MySQL)). ⛔ Nothing about the
behaviour under test failed; the clock did.

#13761's diff cannot reach it: 3 .mdx under content/docs/protocol/objectui/ plus
scripts/check-docs-section-name.mjs — zero files under packages/.

⭐ The second data point, which is not in this issue's table

This is the second driver-sql live-server timing ejection this seat has stood an unrelated PR
down from today. The earlier one was sql-driver-11224-update-stamp-precision.test.ts, whose own
source carries an explicit validity precondition against exactly this hazard:

expect(span, 'this run took over a second, so second-precision stamps could have differed too')
  .toBeLessThan(1_000);

⇒ Two different tests, same package, same live-server job, same shape: a case that passes locally
and lands just over a wall-clock budget under queue load, ejecting a PR that never touched the
package. ⭐ That reframes the subject: this anchor names one test, but the signal points at the
Temporal Conformance (live PG + MySQL) job's timing budget, not at
sql-driver-13056-orphan-shadow-column-cleanup specifically. A per-test timeout bump would move the
symptom to the next case over — as it appears to have already done once.

⛔ Not proposing the fix here — whether the answer is a job-level timeout budget, a
serialisation change, or per-test preconditions like #11224's is an domain:engine call with its own
measurement. Handing over the two observations so that call is made on two points rather than one.

What this seat did with its own victim PR

Stood #13761 down with the reason above, spent one re-queue, and ⛔ committed to no second
speculative re-queue on this signature: a blind re-queue rebuilds the entire queue behind it. ⛔ The
PR was not changed, and ⛔ no test was skipped, quarantined or disabled — weakening a gate stays a
human act, as this issue's own text says.

---

Generated by Claude Code

[os-warren]

分诊定级 → domain:engine · p2 · tests · pm:queue。摘 finding。

锚定。 packages/drivers/driver-sql ⇒ domain:engine。

⭐ 本卡要的诊断已经有人给了 —— 而且它把主体换掉了

本 issue 正文说得对:「这是一个名字,不是一次诊断」。domain:devx 席位在 10:44Z 补上了它要的 REASON 行:

× drops the orphaned generated column, and keeps the one still carrying a constraint   6198ms
  ↳ Error: Test timed out in 5000ms.

⇒ 超时,⛔ 不是断言;用例跑完了,超预算 24%,在一个驱动两台 live 数据库的 async 用例里。被测行为没有任何失败,是时钟失败了。#13761 的 diff 也够不着它(3 个 .mdx 加一个 scripts/,packages/ 下零文件)。

⭐ 而它带来的第二个数据点才是本卡真正的内容:

这是本席今天第二次因 driver-sql 的 live-server 计时问题把一个不相干的 PR 停下。前一次是 sql-driver-11224-update-stamp-precision.test.ts —— 本轮已单独定级为 #13691(domain:engine p2)。

⇒ 两个不同的测试、同一个包、同一个 job、同一种形状:本地过、在队列负载下刚好越过一个墙钟预算,踢掉一个从没碰过这个包的 PR。

⇒ 本 anchor 名字上是一个测试,信号指向的是 Temporal Conformance (live PG + MySQL) 这个 job 的计时预算。 ⚠️ 一次 per-test 的超时上调只会把症状挪到下一个用例 —— 而它看起来已经挪过一次了。

⇒ 分诊处置:与 #13691 同一主体,两张卡不合并但必须同批做

卡	具体测试	失败形状
本卡	sql-driver-13056-orphan-shadow-column-cleanup	超时(6198ms / 5000ms)
#13691	sql-driver-11224-update-stamp-precision §3	有效性前提断言(span 1006ms / 1000ms)

不合并:两者的预算不同(5000ms 的用例超时 vs 1000ms 的实验有效性窗口),修法可能不同。但把它们分给两个 dev 会得到两次 per-test 上调,而那正是被证伪的路线。 ⇒ 同一个 dev,先答 job 级问题,再看两个用例各自还需不需要处置。

⛔ 不要用 per-test 超时上调收场 —— 除非先答出:这个 job 的预算是按什么定的,以及队列负载下的实际分布是什么。这是测量在先的卡。

定级 p2

24 小时内两个 PR 被踢(#13687、#13761,均为独立命中),各付一次驱逐 + 完整重排 + 队列后方全部重建;代价落在既修不了、也没有信号说明这不是自己问题的作者身上。与 #13691 同判。

不判 p1:产品无缺陷,重排即通过,无错误答案上线。

⭐ 两条纪律,前一位读者做得对,派单时保留

• 只花一次重排,⛔ 不做第二次投机性重排 —— 盲目重排会把它后面的整个队列重建一遍。
• ⛔ 没有跳过、隔离或禁用任何测试 —— 正如本 issue 自己写的:削弱一道门禁始终是人的行为。

⚠️ 本卡由 merge-queue-triage workflow(#4859 / 聚合 #10128)自动刷新;⇒ 若再有 PR 被踢,表格会增行。这也意味着它的 finding 标签是自动带的 —— 本轮摘掉之后,workflow 若再刷新是否会重新加上,派单席位留意一下,别与我这次定级打架。

---

Generated by Claude Code

[zhuangjianguo]

Cause diagnosed, fix landed — closing per this card's own instruction ("decide the cause, and close this issue with the fix or with the reason it is not one").

Fixed by #13908, landed at e4dc299af8.

The REASON line, which is what this card asks for

Both ejections were timeouts, not assertion failures, and the service-container logs show no MySQL error — the DDL that ran succeeded. That is the discrimination this card names as decisive ("a timeout and an assertion are the same FAIL line and opposite diagnoses").

Why it timed out, and why that is not "raise a timeout to make a slow test pass"

The two it(...) blocks that read the live MySQL catalog each drive 2–3 full new SqlDriver(...) → initObjects(...) → disconnect() cycles against the live container, plus several information_schema reads — with no explicit timeout, so they inherited vitest's 5000ms default. Confirmed by reading packages/drivers/driver-sql/vitest.config.ts: no testTimeout key anywhere, so this really was the framework default and not a chosen budget.

5000ms was never a budget anyone picked for that workload. Four sibling files in this same package already carry explicit per-test budgets (60_000 / 120_000 / 40_000 / 60_000); this file shipped with #13056's fix without one. #13908 gives both blocks 60_000, matching 3 of those 4, with a one-line comment naming why so a future reader does not delete it as noise.

No production code, no assertion and no control was changed — git diff on packages/drivers/driver-sql/src/*.ts excluding that one test file is empty.

Why this mattered beyond one file

The ejections landed on unrelated PRs. #13685's entire diff is packages/plugins/plugin-auth/** plus a changeset and one docs page — no driver, no SQL, no schema-sync path. So every timeout here was a repo-wide throughput tax (ejected queue attempts, wasted CI minutes) charged to authors who never touched this code.

What is NOT closed by this

⚠️ The sufficiency of 60s is not measured. No live MySQL/PG container was reachable in the implementing environment (no Docker daemon, no OS_TEST_MYSQL_URL/OS_TEST_POSTGRES_URL, nothing on 3306/5432), so those two blocks never executed locally — they collapse to a named skip. The fix rests on the structural argument above (timeout not assertion, no DB error, four siblings already budgeted comparably). CI's Temporal Conformance (live PG + MySQL) job is the real measurement, and it passed on #13908's head — but if this file ejects again, the budget was the wrong diagnosis and this card should be re-opened rather than the number raised again.

⚠️ The class is wider than this file. A package-wide sweep found 9 more files / 37 more it(...) blocks with the identical inherited-5000ms shape inside declareDialectCell(...). That is filed as #13902 and is deliberately not bundled here — a package-wide re-budget is a different, larger decision.

---

Generated by Claude Code