fix(ci): no-op touch to re-register the autofix workflow triggers - #9479
Merged
Conversation
Since ~2026-08-19 00:00 UTC the workflow's schedule, issue_comment, and pull_request triggers stopped creating runs while pull_request_review kept working; dispatch runs were created but never expanded into jobs (three sat queued with zero jobs for 4-11 hours). The on: block was unchanged throughout and a disable/enable cycle did not restore dispatch, consistent with a stale trigger registration on the Actions backend. Any content change forces a re-parse; this commit is that change (one comment line).
Collaborator
|
✅ Qwen Triage finished — CI landed green on ✅ Qwen Triage 已完成 —— |
Collaborator
|
Thanks for the PR! Template looks good ✓ Problem: observed, and I re-verified it against the Actions API rather than taking the description at face value — it holds up exactly. Last Direction: aligned — this restores the repo's own autofix automation. No product surface, no policy area involved. Size: not applicable (no core paths; +2 comment lines in a CI workflow). Approach: this is the minimal possible change — two comment lines inside the existing header block, just enough of a content change to force Actions to re-parse and re-register the file, with zero behavioral delta. The disable/re-enable cycle at 12:28 UTC already failed to restore the dead triggers, so a content-level re-parse is the right next lever. One non-blocking nit: the description says "five triggers" but the file has six Risk: no high-risk path matches; no elevated risk signals. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题： 已观测，且我没有直接采信描述，而是通过 Actions API 独立复核——全部吻合。最近一次 方向： 对齐——恢复仓库自身的 autofix 自动化，不涉及产品面，也不涉及任何策略领域。 规模： 不适用（未触及核心路径；仅 CI workflow 中 +2 行注释）。 方案： 这是最小改动——在既有头部注释块中加两行注释，刚好构成一次内容变更以强制 Actions 重新解析并重新注册该文件，行为零差异。12:28 UTC 的禁用/重新启用周期已确认无法恢复死掉的触发器，因此内容级重新解析是下一步正确的手段。一个非阻塞的小问题：描述说"五个触发器"，但文件实际有六个 风险： 未命中高风险路径；无升级风险信号。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
Code reviewIndependent baseline before reading the diff: to force Actions to re-register a stale workflow, the cheapest lever is any byte change to the YAML — a The diff does exactly the minimal thing: two comment lines at column 1, appended to the existing header comment block immediately above One non-blocking observation on the audit trail itself: the new comment names No sequence diagram or files table — one file, two comment lines. Testing evidenceWorkflow-metadata change, so there is no product behavior for unit tests to pin, and per the gate rules no PR-derived code was executed (there is none to execute). What this review verified:
CI status on the reviewed commit at review time, quoted from the check-runs API: Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 No failures so far. The ubuntu unit suite (the gate to watch; full profile, since workflow files are not in the classifier's lightweight allowlist) was still running at review time — the finalize job will update the table when it lands. The three ⏭️ skips are by design, not a signal about this PR: 中文说明代码审查读 diff 之前的独立方案：要强制 Actions 重新注册过期的 workflow，最廉价的手段是对 YAML 做任意字节变更——加一行 diff 做的正是最小改动：两行注释位于第 1 列，追加在既有头部注释块末尾、紧邻 一个针对记录本身的非阻塞观察：新注释把死掉的事件写作 不附时序图与文件表——单文件、两行注释。 测试证据纯 workflow 元数据变更，没有单测能钉住的产品行为；按门禁规则也未执行任何 PR 派生代码（本 PR 也没有可执行内容）。本审查实际验证了：
审查时刻被审 commit 的 CI 状态，引自 check-runs API（见上方表格）：主门禁 ubuntu 单测套件仍在运行（完整 profile——workflow 文件不在分类器的轻量白名单里）；Desktop Shell 双平台、依赖 CVE 审计、密钥扫描、PR 分类等均已通过；暂无任何失败。三个"跳过"是设计使然而非本 PR 的信号： — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
|
Confidence: 5/5 — the failure was verified end-to-end against the Actions API, and the fix is the smallest byte-change that can address it; nothing to weigh. Reflection, honestly: I went in expecting this to be cargo-culting — "touch the file and hope" — but the evidence pattern changes the picture. The dead and alive lanes partition cleanly along the trigger-registration boundary, not a logic one: every lane whose events route through the same backend registration ( Independent proposal: I'd have done exactly this — any byte change forces a re-parse, and a comment is the only variant that cannot alter behavior while leaving an audit trail. The diff matches it; the one wart is that the audit trail names the wrong lanes (the verified dead set is Approval is deferred until CI lands green — 中文说明Confidence: 5/5 —— 故障已通过 Actions API 端到端核实，而修复是能解决问题的最小字节变更；没有任何需要权衡的地方。 如实反思：我起初以为这是"碰碰文件碰运气"式的迷信，但证据的分布改变了判断。死掉与存活的通道沿着触发器注册边界干净地分开，而不是沿着逻辑边界：所有事件经由同一后端注册路由的通道（ 独立方案：我也会这么做——任意字节变更都能强制重新解析，而注释是唯一既不可能改变行为、又能留下操作记录的变体。diff 与方案一致；唯一的瑕疵是操作记录写错了通道名（已核实的死掉集合是 批准推迟到 CI 落绿—— — Qwen Code · qwen3.8-max Reviewed at |
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
approved these changes
Aug 19, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
qwen-code-ci-bot
approved these changes
Aug 19, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
No issues found. LGTM! ✅
Not explored to full depth (tool budget reached): "agent 6a": none — no check was cut short..
Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
未发现问题。LGTM！✅
未探索到全部深度（达到工具调用预算）："agent 6a"：none — no check was cut short.。
未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max via Qwen Code /review (v0.21.14)
doudouOUC
approved these changes
Aug 19, 2026
doudouOUC
left a comment
doudouOUC
left a comment
Collaborator
There was a problem hiding this comment.
审查结果
无问题。LGTM！✅
该 PR 仅对 🧭 phase='auto' event='' issue='#n/a' pr='#n/a' schedule='n/a' dry_run=false → issue=false review=false 添加了一行注释，用于强制 GitHub Actions 重新解析工作流触发器注册。这是 GitHub Actions 后端触发器注册过期的标准补救措施。
已验证：
- YAML 语法正确解析 ✅
- 注释位置正确（在 触发器块之前的注释区）✅
- 无行为变更、无安全风险 ✅
- CI 已通过 ✅
No issues found. LGTM! ✅
This PR adds a single comment line to 🧭 phase='auto' event='' issue='#n/a' pr='#n/a' schedule='n/a' dry_run=false → issue=false review=false to force GitHub Actions to re-parse and re-register the workflow trigger registration. This is the standard remedy for stale Actions workflow trigger registrations.
Verified:
- YAML parses correctly ✅
- Comment placement is correct (in the comment block before the section) ✅
- No behavioral changes, no security concerns ✅
- CI passed ✅
Collaborator
|
Released in v0.21.15. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Adds a single comment line to the autofix workflow so merging forces GitHub Actions to re-parse and re-register the workflow. No behavior change: the trigger block, jobs, gates, and steps are all byte-identical except the comment.
Why it's needed
Starting around 2026-08-19 00:00 UTC, three of the workflow's five triggers stopped producing runs: the ten-minute schedule ticks stopped after 2026-08-18 23:51 UTC, issue-comment events stopped matching after 00:16 UTC even though sibling workflows received the same events seconds later, and label toggles stopped routing. Meanwhile dispatch runs were created but never expanded into jobs — three sat queued with zero jobs for 4 to 11 hours. The review-event lane kept working throughout, which is why the loop looked half alive. The trigger block was unchanged across this window (the last two merges touching the workflow only modified step bodies), and a disable/re-enable cycle at 12:28 UTC did not restore the dead triggers either — later comment events created runs for every other issue-comment workflow except this one. The pattern points at a stale trigger registration for this specific workflow on the Actions backend, and the standard remedy is any content change forcing a re-parse.
Reviewer Test Plan
How to verify
After merge, watch the Actions tab: the next ten-minute tick should create a schedule run of this workflow, and any new PR/issue comment should create an issue-comment run (almost always
skipped— that still proves dispatch). End-to-end: re-issue@qwen-code /takeoveron a PR and confirm the label toggles.Evidence (Before & After)
Before (Actions API): latest issue_comment run 2026-08-19T00:16:07Z despite continuous comment traffic; latest schedule run 2026-08-18T23:51:23Z despite the */10 cron; dispatch runs 32203631619 / 32206055039 / 32217861831 queued with zero jobs for 4–11 hours; the 06:06:55Z comment created runs in the four sibling workflows but not in this one. After: to be filled post-merge.
Tested on
Environment (optional)
N/A — workflow-metadata-only change; verified the YAML still parses and the trigger block is intact after the change.
Risk & Scope
Linked Issues
None.
中文说明
本 PR 做了什么
为 autofix workflow 增加一行注释，使合入时强制 GitHub Actions 重新解析并重新注册该 workflow。无行为变化：触发器块、jobs、门禁与步骤除注释外逐字节一致。
为什么需要
自 2026-08-19 约 00:00 UTC 起，该 workflow 五个触发器中的三个停止产生 run：每 10 分钟的 schedule 在 2026-08-18 23:51 UTC 后不再创建 run；issue comment 事件在 00:16 UTC 后不再匹配（而同类 workflow 数秒后仍能收到同样的事件）；label 变更也不再路由。同时 dispatch run 能创建但从不展开成 job——三个 run 以 0 个 job 的状态排队卡了 4 到 11 小时。review 事件通道全程正常，因此整个循环看起来"半活"。这段时间触发器块没有任何变化（最近两次触及该 workflow 的合入只改了 step 内的 bash 内容），12:28 UTC 的禁用/重新启用也未能恢复死掉的触发器——之后的评论事件为其他所有 issue_comment workflow 创建了 run，唯独没有这个。这些迹象指向 Actions 后端对这个特定 workflow 的触发器注册状态过期，标准补救方式是用一次内容变更强制重新解析。
审阅者测试计划
如何验证
合入后观察 Actions 页面：下一个 10 分钟整点应为该 workflow 创建 schedule run；任何新的 PR/issue 评论应创建 issue-comment run（几乎总是
skipped——但这仍证明事件派发已恢复）。端到端验证：对某个 PR 重新发送@qwen-code /takeover，确认标签被切换。证据（改动前后）
改动前（Actions API 查询）：issue_comment 最新 run 为 2026-08-19T00:16:07Z，而评论一直持续；schedule 最新 run 为 2026-08-18T23:51:23Z，而 cron 是 */10；dispatch run 32203631619 / 32206055039 / 32217861831 以 0 个 job 排队 4–11 小时；06:06:55Z 的评论为其他 4 个同类 workflow 创建了 run，唯独没有这个。改动后：合入后补充。
测试环境
运行环境（可选）
N/A——仅 workflow 元数据变更；已验证改动后 YAML 仍可解析、触发器块完整。
风险与范围
关联 Issue
无。