Skip to content

Queue-flake anchor: test/serve-publishes-bound-port.e2e.test.ts #13175

Closed as duplicate

Description

@github-actions

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.

PR stack queue build
#13051 independent 33242330316
#13107 independent 33237340137
#13124 S3 · root 33240054144
#13125 S3 · inherited 33240068158
#13130 independent 33239036507
#13133 independent 33238180927
#13140 independent 33240915666
#13142 S3 · inherited 33240069522
#13145 independent 33241594487

⚠️ 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.

Last refreshed by queue build 33242330316 (PR #13051).


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

Activity

  1. added
    findingRecorded observation — held, not dispatchable until the findings triage round grades it
    on Aug 29, 2026
  2. huangyiirene commented on Aug 29, 2026

    @huangyiirene
    Collaborator

    去重:与 #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,锚点查找:

    const ANCHOR_LABEL = 'finding';
    const res = await github.rest.issues.listForRepo({
      owner, repo, state: 'open', labels: ANCHOR_LABEL,   // ← 先按 finding 过滤
      sort: 'created', direction: 'desc', per_page: 100, page: p,
    });
    existing = res.data.find((i) => !i.pull_request
      && (String(i.body ?? '').includes(anchorMarker) || i.title === title)) ?? null;

    ⇒ 两条身份通道(body marker 与 title)都在 labels: 'finding' 过滤之后才生效。 一旦锚点掉了 finding,两条通道同时失效,workflow 找不到它,于是新建一张。

    ⚠️ 而 finding 正是分诊席位定级后会摘掉的标签(本仓「定级即离标」约定)。⇒ 分诊的约定与这个 workflow 的锚点键直接冲突:分诊每定级一次这类卡,就会让它在下一次弹出时被复制一次。

    时间线与之吻合:#13158 在 07:38Z 前后处于无 finding 状态,本卡创建于 07:45:35Z。⛔ 我不断言是谁摘掉了那次标签(我在 R+17 的回读里看到 workflow 于 07:29Z 把它加了回去,之后它又被移除,而我没有该次写入的记录)——但机制是确定的,责任归属不影响结论。

    ⭐ 代码里那句注释读起来格外可惜:

    "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."

    作者预见到了重复这个失效模式,并为此做了两条冗余的身份通道——但两条都被它们上游那个 labels 过滤器一起废掉了。⇒ 这是本周反复出现的那一族的又一例:一个机制拥有的覆盖面小于它声称的,而且这次是"两条备份路径共用一个单点故障"。

    处置


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    findingRecorded observation — held, not dispatchable until the findings triage round grades it

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions