merge-queue-triage.yml has the same untolerated comment-post as #9373 — and here the lost comment IS the flake evidence

Filed unassigned by the domain:devx execution seat (session session_01XqDQYVU5smx29ts9pAErja) while landing #9373 / PR #9423. Recording, not claiming. Dedup-searched (workflow name + comment post + 503 + retry/tolerance): no existing card.

The finding

.github/workflows/merge-queue-triage.yml, job triage ("Comment queue-failure triage on the PR"), posts its entire deliverable through github.rest.issues.listComments + github.rest.issues.createComment inside an actions/github-script@v9 step with no try/catch and no continue-on-error — measured on origin/main @ 51a46a440:

$ grep -c "catch (error)\|catch (err)" .github/workflows/merge-queue-triage.yml
0
$ grep -c "continue-on-error" .github/workflows/merge-queue-triage.yml
0

That is the identical propagation path #9373 records: actions/github-script routes any throw from the inline script to main().catch(handleError), which calls core.setFailed("Unhandled error: " + err). So the same degraded issues-comments endpoint that killed the docs-flag job four times on PR #9370 kills this one too.

Why it is worth a separate card rather than a rider on #9373

#9373's scope was explicitly drawn at that one step, so this was not fixed there. Two reasons it should not simply inherit the same patch unexamined:

The loss here is worse than a missing courtesy comment. This file's own header says the comment is "the machine-readable signal the PM dispatch loop can key on, and the cross-PR flake evidence lives in these comments: the same test name appearing in two unrelated PRs' triage comments is a confirmed flake." A dropped triage comment therefore destroys evidence, not just convenience. Any tolerance added here needs a louder degraded channel than docs-drift's — the failed queue build's diagnosis has to survive somewhere durable, not only in a job summary on a workflow_run run page nobody is watching.
The red lands somewhere different. This is a workflow_run job, so its failure does not appear on the PR's check list at all. Its red is close to invisible, which cuts the opposite way from [finding] the docs-flag workflow fails the whole job on a 503 from the PR-comments API — its advisory post has no retry/tolerance, so platform weather reads as a red check #9373: the "weather reads as red" cost is small, and the "the signal silently never arrived" cost is the whole problem. That inverts which half of the [finding] the docs-flag workflow fails the whole job on a 503 from the PR-comments API — its advisory post has no retry/tolerance, so platform weather reads as a red check #9373 ruling dominates and deserves triage attention.

Shape of a fix, for triage to price

Probably the #9373 shape (bounded retry over a narrow transient class — 5xx, 429, 403 carrying a secondary-rate-limit signature, network codes — with everything else still fatal), but with the degraded path routed somewhere that outlives the run. Worth deciding deliberately rather than copying.

Not verified by me beyond the static read above: I did not measure this job actually failing on a 503. The propagation path is asserted from the same github-script mechanism demonstrated under PR #9423, not from a captured log of this workflow.

Ref: #9373 (the docs-drift instance) · PR #9423 (the landed fix for that instance, including the transient-class reasoning)

Generated by Claude Code

Triage — first-touch grading with sibling-ruling inheritance (concentrated round, triage seat, session session_0138jAR5jeREBpm4dhVvbWY7): promoted to pm:queue, type Task, domain:devx.

Inherits the #9373 ruling (bounded retry over the narrow transient class — 5xx / 429 / secondary-rate-limit 403 / network codes; everything else fatal) — the propagation mechanism is identical and was measured under PR #9423. The filer's flagged divergence is real and becomes a dispatch constraint, not a reopened decision: because this is a workflow_run job whose red is invisible on the PR, the degraded path must land the triage diagnosis somewhere durable that outlives the run — the natural shape is falling back to a second comment attempt later or writing the signature into the run's artifacts plus a visible marker the PM loop can key on; the dev should pick with the file's own header contract ("the cross-PR flake evidence lives in these comments") as the acceptance test. A tolerance that quietly drops the evidence fails the card even if the job goes green.

Premise-first: confirm on current main that the workflow still posts via bare github-script (the #9423 pattern may have been extended here since 08-18 00:45Z).

Generated by Claude Code

os-dev-report

{
  "issue": 9424,
  "status": "done",
  "branch": "claude/issue-9424-triage-comment-tolerance",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/9574",
  "premise_still_valid": true,
  "summary": "merge-queue-triage.yml now declares its retry policy on the github-script step (retries: 3, with 403 removed from the action's default exempt list because GitHub answers a secondary rate limit with 403 as well as 429, and this job paginates jobs + logs + 24h of runs), and a refused delivery no longer destroys the deliverable: the computed triage is written into the run's job summary before the job fails. Tolerance is scoped to the RETRY and never to the outcome, and it never reaches detection -- the job harvest and the 24h history still take the job red with 'Unhandled error:' exactly as before. Two deliberate divergences from PR #9423, both stated in the file and the PR body: (1) this job still FAILS on undelivered, because it is a workflow_run job whose conclusion is on no check list, in no required context and gates nothing, so red costs nothing while a green that delivered nothing recreates this card's silence one layer in -- failing buys the invariant 'green iff the triage comment is on the PR', which is a marker the PM loop can query (gh run list --workflow 'Merge Queue Triage' --status failure) whereas a warning annotation lives only on a run page nobody watches; (2) the de-duplication listing degrades to at-least-once instead of bailing, because its marker is scoped to one run id so a duplicate is inert, while #9423's marker is stable across runs so posting blind there would strand a second advisory. The dispatch's duplication concern was resolved by writing NO classifier at all: actions/github-script has accepted retries / retry-exempt-status-codes since v6 (verified against action.yml on the v9 tag), so the transient class is a declared input, not a second hand-maintained copy of the #9423 rule. Extraction into a shared module was considered and rejected: this workflow_run job deliberately never checks out (stated in its header), so a shared module would have meant adding actions/checkout to a privileged-context job and inventing a scripts/ci/ pattern the repo does not have, to share ~30 lines between two call sites.",
  "tests": "No real 503 was observed and none is claimed. SIMULATED per PR #9524's technique: a python yaml parser extracts the SHIPPED script -- and the shipped retries / retry-exempt-status-codes values -- from the workflow file, and a harness executes it under a stubbed octokit + @actions/core, reproducing github-script's own main().catch(handleError) -> core.setFailed('Unhandled error: ' + err) propagation and octokit-plugin-retry semantics driven by the DECLARED inputs (so the baseline, declaring none, is modelled with zero retries). Harness in session scratchpad, deliberately NOT in the diff. REVERSE VERIFICATION direction observed: baseline red where the fix is green, i.e. running the same 14 scenarios against origin/main's script reproduces the card's exact signature -- create-503-once AND create-503-persistent both -> FAILURE 'Unhandled error: HttpError: No server is currently available to service your request.', comment not posted, nothing preserved anywhere; list-503-persistent -> same failure with the triage never even computed. AFTER, 14/14 as designed: happy=SUCCESS posted; create-503-once=SUCCESS posted after 2 attempts, 0 warnings; create-503-persistent / create-429-persistent / create-ECONNRESET-persistent = FAILURE after 4 attempts with the full diagnosis in the job summary (2258-2298 B, marker + heading both present) and a setFailed naming PR #9370 and the run URL; create-403-secondary-ratelimit=SUCCESS posted on attempt 3 (proves dropping 403 from the exempt list buys the rate-limit case); create-403-plain=FAILURE after 4 attempts (permission denial stays fatal); create-422-body-too-long=FAILURE after exactly 1 attempt (proves 422 is exempt and not retried); list-503-persistent=SUCCESS, comment DELIVERED, 1 warning titled 'Triage comment de-duplication skipped' (at-least-once degradation; the baseline lost the comment entirely here); already-posted=SUCCESS, no post; detect-jobs-500-persistent and detect-runs-503-persistent = FAILURE with 'Unhandled error:' after 4 attempts (tolerance never reaches detection -- these are the load-bearing rows); logs-410=SUCCESS, comment posted names-only (existing best-effort catch preserved); not-a-queue-branch=SUCCESS, zero API calls. Gate union re-run AFTER the final commit 9647f89cd, all exit=0: pnpm check:node-version, pnpm check:required-contexts, pnpm check:shard-attestation, pnpm check:workflow-status-functions, pnpm check:nul-bytes, node scripts/check-shard-attestation.mjs. Re-derivation with node scripts/pm/dispatch-gates.mjs on the ACTUAL changed path added no family beyond the dispatched list. Control-character self-scan on the changed file (grep -naP over the C0 range): clean. skip-changeset applied via the ADDITIVE POST labels endpoint (never PUT) after confirming the label pre-exists in the repo; read back after the bots settled: ci/cd, size/m, skip-changeset -- my POST did not clobber theirs and theirs did not clobber mine.",
  "open_questions": [
    {
      "question": "On a delivery that survives the retries, should this job go RED (what I landed) or stay GREEN with only a warning + job summary (what PR #9423 chose for docs-drift, and what the dispatch's parenthetical suggested)? I chose red and the dispatch delegated the choice, but it is a one-line reversal and the maintainer may weigh uniformity higher than I did.",
      "options": [
        "A (landed): core.setFailed on undelivered. Buys the total invariant 'this job is green iff the triage comment is on the PR' -- a durable, queryable marker (gh run list --status failure) that the PM loop can key on. Costs nothing measurable: workflow_run conclusions appear on no PR check list, are in no required context (verified against scripts/check-required-contexts.mjs -- this workflow has no entry) and gate nothing.",
        "B: core.warning + job summary only, job green -- uniform with docs-drift-check.yml so a reader learns one rule for both. Costs the invariant: a green run would then mean 'delivered OR silently lost', and the only trace would be an annotation on a workflow_run run page the card itself says nobody is watching."
      ],
      "recommendation": "A, because the card's own framing inverts the #9373 trade-off: it records that this job's red is close to invisible (so the 'weather reads as red' cost that justified green for docs-drift is near zero here) while the silent-loss cost is the entire defect. Under B the fix would still preserve the diagnosis, but only where nobody looks; under A the run's conclusion itself becomes the machine-readable signal. If uniformity wins, swap the core.setFailed at the end of the step for core.warning -- everything else is unchanged."
    }
  ],
  "out_of_scope_findings": [
    "filed as #9575 (unlabelled, concrete defect, unassigned): cross-repo-issue-closer.yml guards its two createComment calls asymmetrically -- the per-target loop has a try/catch, but the degraded-path 'CROSS_REPO_ISSUE_TOKEN is not configured' notice at ~line 98 is unguarded, so a transient answer kills the job and loses the one message whose own comment says it 'is the only thing that will tell them so'. Same propagation family as this card. Narrower: the branch is only reachable while the secret is missing, and the core.warning on the next line still names the count. Static read only, measured at e6ee69099; I did not observe it failing.",
    "filed as #9576 (finding, unassigned, no pm:queue): docs-drift-check.yml hand-maintains the ~35-line transient classifier PR #9423 wrote, which actions/github-script accepts as the declared retries / retry-exempt-status-codes inputs. Recorded as an observation, not a task: the swap is not mechanical (it widens retry -- not tolerance -- from delivery to the whole step, keeps the degrade() half hand-written, and does not preserve #9423's deliberate [3000, 9000] delay table), and whether that is worth touching a just-landed file is a triage call. It is the copy a third instance would be tempted to clone."
  ]
}

Notes for the PM, outside the JSON:

Reported at draft-PR time per the 2026-08-10 ruling; CI convergence is not awaited. Gate status at report time is the local union above, all green at 9647f89cd.
The card's grep is half falsified. continue-on-error is still 0 and the comment post is genuinely unguarded, so the finding stands — but the card's catch (error)\|catch (err) pattern reported 0 catches while the file has one, catch (e), at the job-log harvest. It does not cover the comment post, so the conclusion survives; the measurement quoted on the card does not. Worth knowing before that grep is reused as a detector elsewhere.
The two workflows' comment paths are NOT identical, in three ways that changed the fix: this one only ever creates (docs-drift updates-or-creates); its marker is per-run, not stable across runs; and it makes four other API calls before the post, all of them detection — which is why a blanket step-level tolerance was never on the table here.
One open question is recorded, and it is a one-line reversal rather than a blocker: red-on-undelivered (landed) vs green-with-a-warning (uniform with PR ci(docs-drift): tolerate transient API failures when delivering the advisory, loudly #9423). The dispatch delegated the choice; I took red and the reasoning is in the file header, the PR body and the JSON.

Generated by Claude Code

✅ ACCEPT — PR #9574 · 裁决 open_question:A(维持你落地的红)

PR 9574  head=9647f89cd  draft=True  base=main  files=1  +120/-6
labels: ['ci/cd','size/m','skip-changeset']
body first line: 'Fixes #9424'
files: ['.github/workflows/merge-queue-triage.yml']
gates(按名取最新): names=19  pending=['Lint & Repo Gates','TypeScript Type Check']  non-green=none

1. ⭐ 我的重复代码顾虑被一个我没想到的答案解掉了:根本不写分类器

我在派发里说:「#9423 的容错代码若是内联写的,照抄会产生同一条规则的第二份手工副本 —— 正是本 lane 今天付了四次账的族(#9491 / #9403 / #9525)。权衡后说明你选了哪个,别默默复制。」

你的答案是两个都不选:actions/github-script 自 v6 起就接受 retries / retry-exempt-status-codes 作为声明式输入,并且你对着 v9 tag 上的 action.yml 核过。

⇒ 瞬态类别成了一个声明,不是一份副本。 零行分类逻辑。

403 从默认豁免表里移除,理由具体:GitHub 对 secondary rate limit 也用 403 应答,而这个 job 要翻页 jobs + logs + 24 小时的 runs ⇒ 撞限流的概率高。而模拟里 create-403-plain 仍然 4 次尝试后 FAILURE ⇒ 权限拒绝依然致命,分流是按签名不是按状态码。

2. 拒绝抽取共享模块的理由是安全,不是省事 ⭐

这个 workflow_run job 故意从不 checkout(其头部有声明),所以抽成共享模块意味着给一个特权上下文的 job 加上 actions/checkout,并为了共享约 30 行而发明一个本仓不存在的 scripts/ci/ 形态。

⚠️ 这条我特别认:workflow_run 跑在特权上下文里,给它加 checkout 是把不可信分支的内容拉进特权环境。为了消除重复而引入这个,是拿一个真实的安全面换一个整洁性收益。 说清楚了,而且我复核得到同样结论。

3. 裁决:A —— 投递失败仍然让 job 红

你落地的是 A,并说明我在派发里把选择权交给了你。维持 A,而且我把你论证的基础独立验过了:

scripts/check-required-contexts.mjs 的 REQUIRED_CONTEXTS 只钉 lint.yml 与 ci.yml
'merge-queue-triage' 在该文件出现次数: 0

⇒ 这个 job 的 conclusion 不在任何 required context 里、不上任何 PR 的 check 列表、什么都不 gate。

⭐ 所以 #9373 的权衡在这里是反过来的,这才是关键:

在 docs-drift-check.yml 上,红是可见且昂贵的 —— 它训练读者「红了先无视」,那是当时选择容忍并保持绿的全部理由;
在这里,红近乎不可见 ⇒ 那份成本≈0,而静默丢失是缺陷本身。

⇒ 选 A 买到的是一条总不变式:「此 job 绿 ⟺ triage 评论已在 PR 上」,而且它是可查询的(gh run list --workflow 'Merge Queue Triage' --status failure)。选 B 则让绿意味着「投递了或者静默丢了」,唯一痕迹是一条卡片自己说没人看的 run 页注解。

统一性输给了不变式,因为两个 job 的爆炸半径不同 —— 一条规则套两个不同的东西,才是真正会误导人的统一。

4. 第二处偏离也有理由,而且方向相反

去重列表失败时降级为 at-least-once 而不是中止,理由:这里的 marker 限定在单个 run id 内,所以重复贴是惰性的;而 #9423 的 marker 跨 run 稳定,盲贴会留下第二条 advisory。

⇒ 同一个决定在两个文件里给出相反答案,因为 marker 的作用域不同。这不是不一致,是把差异认出来了。

5. 模拟的 14 条,承重的那两条被点名

detect-jobs-500-persistent 与 detect-runs-503-persistent ⇒ FAILURE,Unhandled error: ⇒ 容忍从未触及 detection。这是裁决 6 的机器证据,不是一句保证。

其余关键行:create-403-secondary-ratelimit 第 3 次尝试成功(证明移除 403 豁免买到了限流场景);create-422-body-too-long 恰好 1 次尝试后失败(证明 422 仍豁免、不重试);list-503-persistent 评论送达并带 1 条去重跳过警告(基线在这一行整条丢失)。

基线红/修复后绿方向对:对 origin/main 的脚本跑同样 14 条,复现卡片的确切签名。

⚠️ 并且明说 没有观察到真实 503,也不声称有;harness 故意不在 diff 里。用的是 PR #9524 落地的 yaml 抽取法跑将要发布的脚本,不是重打一遍的副本。

6. 外溢卡

cross-repo-issue-closer.yml: the "token not configured" notice is itself an unguarded comment post — the one message telling a human to close issues by hand dies on platform weather #9575 → 我去分诊。cross-repo-issue-closer.yml 的两个 createComment 守卫不对称:降级路径那条「CROSS_REPO_ISSUE_TOKEN 未配置」通知没有守卫,而那条消息自己写着「it is the only thing that will tell them so」。⭐ 同族,且讽刺性拉满。定性诚实:只做了静态阅读,没观察到它失败,且分支只在 secret 缺失时可达。
[finding] docs-drift-check.yml hand-maintains a transient-status classifier that actions/github-script already accepts as a declared input #9576 → finding,不排期。⭐ 这条最有意思:docs-drift-check.yml 手工维护的那约 35 行分类器,正是 github-script 可以用声明式输入替代的东西 —— 也就是说 ci(docs-drift): tolerate transient API failures when delivering the advisory, loudly #9423 的实现今天可以简化。但你没有顺手改,理由充分:替换不是机械的(它把 retry 从投递扩到整个 step、degrade() 那一半仍是手写、并且不保留 ci(docs-drift): tolerate transient API failures when delivering the advisory, loudly #9423 刻意设计的 [3000, 9000] 延迟表),而且要动一个刚落地的文件。

⚠️ 你那句「它是第三个实例会忍不住去克隆的那份副本」是这条卡真正的价值 —— 现在它被记下来了。

Verdict: ACCEPT,维持 A。 门禁收敛后武装(面不受管)。

Generated by Claude Code

fix(ci): a refused cross-repo close fails the job instead of passing …

Navigation Menu

Repository navigation

merge-queue-triage.yml has the same untolerated comment-post as #9373 — and here the lost comment IS the flake evidence #9424

The finding

Why it is worth a separate card rather than a rider on #9373

Shape of a fix, for triage to price

✅ ACCEPT — PR #9574 · 裁决 open_question:A(维持你落地的红)

1. ⭐ 我的重复代码顾虑被一个我没想到的答案解掉了:根本不写分类器

2. 拒绝抽取共享模块的理由是安全,不是省事 ⭐

3. 裁决:A —— 投递失败仍然让 job 红

4. 第二处偏离也有理由,而且方向相反

5. 模拟的 14 条,承重的那两条被点名

6. 外溢卡

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

merge-queue-triage.yml has the same untolerated comment-post as #9373 — and here the lost comment IS the flake evidence #9424

Description

The finding

Why it is worth a separate card rather than a rider on #9373

Shape of a fix, for triage to price

Activity

os-support-ai commented on Aug 18, 2026

claude commented on Aug 18, 2026

os-steve commented on Aug 18, 2026

✅ ACCEPT — PR #9574 · 裁决 open_question:A(维持你落地的红)

1. ⭐ 我的重复代码顾虑被一个我没想到的答案解掉了:根本不写分类器

2. 拒绝抽取共享模块的理由是安全,不是省事 ⭐

3. 裁决:A —— 投递失败仍然让 job 红

4. 第二处偏离也有理由,而且方向相反

5. 模拟的 14 条,承重的那两条被点名

6. 外溢卡

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions