You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
test/serve-publishes-bound-port.e2e.test.ts has ejected 9 pull requests from the merge
queue within a rolling 24 hours — 7 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.
⚠️Queue depth is not evidence. The stack column is read out of the queue
branch names: GitHub builds each queued PR on top of the previous entry, so a
build whose BASE commit IS another victim's queue HEAD contains that victim's
tree by construction. A single deterministic break therefore ejects every PR
behind it, and the raw victim count climbs with QUEUE DEPTH until the owner
lands a fix. Start with the roots above; an inherited row is a bystander until shown otherwise.
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.
"the exact title is a second way in, because a body is the one channel GitHub is known to rewrite and an anchor that cannot be found is an anchor that gets duplicated."
Activity
huangyiirene commentedon Aug 29, 2026
去重:与 #13158 是同一个锚点,关为 duplicate
同一个签名键(
test/serve-publishes-bound-port.e2e.test.ts),同一个 workflow 立的卡。本卡数据是 #13158 的超集(8 PR / 6 独立,vs 那边的 6 PR / 4 独立),但那不是两张卡,是同一张卡的两次刷新落在了两个 issue 上。⛔ 保留 #13158(较早、已定级
bug·p1·pm:queue·domain:cli、且带着分诊分析),本卡关闭。本卡的最新计数不会丢——workflow 下次弹出时会把 8/6 刷进 #13158。⭐ 为什么会重复 —— 已从 workflow 源码测出,不是猜
.github/workflows/merge-queue-triage.yml:425-435,锚点查找:⇒ 两条身份通道(body marker 与 title)都在
labels: 'finding'过滤之后才生效。 一旦锚点掉了finding,两条通道同时失效,workflow 找不到它,于是新建一张。finding正是分诊席位定级后会摘掉的标签(本仓「定级即离标」约定)。⇒ 分诊的约定与这个 workflow 的锚点键直接冲突:分诊每定级一次这类卡,就会让它在下一次弹出时被复制一次。时间线与之吻合:#13158 在 07:38Z 前后处于无
finding状态,本卡创建于 07:45:35Z。⛔ 我不断言是谁摘掉了那次标签(我在 R+17 的回读里看到 workflow 于 07:29Z 把它加了回去,之后它又被移除,而我没有该次写入的记录)——但机制是确定的,责任归属不影响结论。⭐ 代码里那句注释读起来格外可惜:
作者预见到了重复这个失效模式,并为此做了两条冗余的身份通道——但两条都被它们上游那个
labels过滤器一起废掉了。⇒ 这是本周反复出现的那一族的又一例:一个机制拥有的覆盖面小于它声称的,而且这次是"两条备份路径共用一个单点故障"。处置
finding(并回读确认),使 workflow 能再次找到它。⛔ 这是对「定级即离标」的一次明确的例外,理由如上,已记录在案而非默默为之。finding不代表未定级——先看有没有domain:*+priority:*。domain:devx,⛔ 不在本卡范围内,也⛔ 不由分诊代改 workflow。已作为独立观察上报。Generated by Claude Code