Repository navigation
Queue-flake anchor: test/serve-publishes-bound-port.e2e.test.ts #13187
Description
Activity
去重：#13158 的第三张同锚点卡，关为 duplicate
同一签名键（
test/serve-publishes-bound-port.e2e.test.ts）。历史：#13158（首张，已定级）→ #13175（R+18 关为重复）→ 本卡。计数仍在增长（本卡 8 PR / 6 独立）。⛔ 计数不会丢：workflow 下次弹出会刷进 #13158。⛔ 我上一轮的修复没有生效，如实说明
R+18 我测出根因（
.github/workflows/merge-queue-triage.yml:425-435：锚点查找listForRepo({ labels:'finding' })，body marker 与 title 两条身份通道都在该过滤之后才生效），并给 #13158 重新贴回了finding、当场回读确认。然后它又被摘掉了。 本轮开轮回读：#13158 现为
["bug","tests","priority:p1","pm:queue","domain:cli"]，无finding；本卡创建于 08:47Z，正好在其后。⇒ ⛔ 我不会再贴第三次。 原因不是放弃，是那样做必然失败且会伤到别人：
finding是本仓所有 PM 席位按「定级即离标」正当摘除的标签，而这个 workflow 拿它当锚点键。⇒ 这是一场我方多个席位与一个 workflow 之间的无界对贴循环，每一方都在正确地执行自己的规则。我再贴一次，只会让下一个跑 finding 清扫的席位再摘一次。⭐ 真正的修复只有一个方向：让锚点查找不依赖一个由分诊拥有、且会被正当摘除的标签——例如全仓搜 body marker，或改用一个 workflow 专用、分诊不碰的标签（
queue-anchor之类）。⛔ 属domain:devx，⛔ 分诊不代改 workflow。已作为本轮头号机制项上报维护者。⭐ 好消息：这件事大概率会自己停
本轮新到的 #13193 给出了这个 flake 的真实诊断（
channelsOf在 banner 出现的瞬间同步读runtime.env_local.json，重载分片下 ENOENT），已定级pm:queue·domain:cli· p1，并与 #13158 互链。⇒ #13193 的修复落地后 ⇒ 不再弹出 ⇒ 不再刷新锚点 ⇒ 重复自然停止。
⚠️ 所以优先级排序是：修 #13193（真缺陷）> 修 workflow 锚点（机制卫生）> 继续对贴标签（⛔ 无用）。⭐ 另记一句给锚点卡读者：本卡计数 8 PR / 6 独立，而 #13193 把它读作 flake。一个 24 小时内独立命中 6 次的竞态不是 flake，是缺陷 —— 我已按缺陷给 #13193 定 p1，理由写在那张卡上。
Generated by Claude Code
test/serve-publishes-bound-port.e2e.test.tshas ejected 14 pull requests from the mergequeue within a rolling 24 hours — 10 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.
stackcolumn is read out of the queuebranch 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
inheritedrow 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 33244436318 (PR #13174).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).