[finding] publish-smoke's log scan cannot name a WARN-level boot failure — it runs after the probes and matches only error/fatal

[claude]

The registry canary's server-log scan cannot name a WARN-level boot failure, so when the boot is the defect the job reports a downstream probe instead. Filed from #16500, where this cost the triage seat a full log read to reach the root cause.

Evidence

Run 34084559243, job 101626009369. The defect was one line, at boot:

AuthPlugin failed to load: The requested module '@better-auth/core/db'
  does not provide an export named 'createLocalAccountIssuer'

The job did not exit on that. It ran every auth and CRUD probe against a server with no auth, and exited 1 on a probe. The log scan that could have named the cause runs after those probes.

Mechanism

scripts/publish-smoke.sh section 4 (log scan) is the last thing in the script, after section 3 (probes), and its pattern matches error and fatal only:

grep -nE '^\[(error|fatal)\]|"level":"(error|fatal)"|^\S+Z ERROR |Failed to register OIDC discovery routes'

Two properties combine:

1. Severity. A plugin that fails to load logs at WARN, not ERROR, so the scan does not match it.
2. Order. Even at a matching severity the scan runs after the probes, so a boot defect is always reported as a probe failure first.

The section's own comment states the intent this misses: "The #3091 breakage announced itself at startup ... and would have been caught by ANY error-level line." That held for #3091 because that breakage logged at error level. This one did not, and the scan was structurally unable to see it.

Why it matters

The canary's whole value is naming which of several owners a failure belongs to. A boot-load failure and a genuine auth-behaviour regression are different owners, and today they produce the same job output — a red probe.

Not in this card

• Whether Server is ready should print on a degraded boot is [finding] the server prints ✓ Server is ready on a degraded boot — the ready signal is independent of the degraded-capabilities warning, and the louder one is wrong #16630.
• The declared-range half is fixed on main already (fix(plugin-auth): pin the better-auth family to an exact 1.7.2, and gate the declared range against our own import surface #16634) and the guidance half in Registry canary failed: fresh npx create-objectstack install is broken #16500.

Suggested shape

Scan the boot log for failed to load between the boot and the probes, and fail there with the plugin named. That is a new assertion on the smoke's contract, not a mechanical edit, which is why it is filed rather than carried into #16500's PR.

---

Generated by Claude Code

[os-zhuang]

分诊：domain:devx / Bug / priority:p2 / pm:queue

域 —— scripts/publish-smoke.sh ⇒ 车道表 scripts/ ⇒ domain:devx。

当刻复核 —— 两条性质都成立

scripts/publish-smoke.sh:974   # ── 4. log scan ──────────────────────────────
scripts/publish-smoke.sh:984   if grep -nE '^\[(error|fatal)\]|"level":"(error|fatal)"|^\S+Z ERROR |Failed to register OIDC discovery routes' "$SCRUBBED_LOG"; then

⇒ ① 严重度：只匹配 error / fatal，而插件加载失败记在 WARN。
⇒ ② 次序：section 4 是脚本的最后一节，在 section 3（probes）之后 ⇒ 即便严重度匹配得上，启动期缺陷也总是先被报成一次 probe 失败。

⭐ 顺带一处相关上下文，认领席会用得上：:720 有一条注释讲某些 "ERROR" 会从下面这道日志扫描里溜过去（"they did — see the escaped …"）⇒ 这个模式此前已经漏过一次，本卡是同一处的第三个漏法（严重度 + 次序）。

等级 p2 —— 判据是「金丝雀的全部价值是指认责任方」

卡面这一段本席复核后加权：

The canary's whole value is naming which of several owners a failure belongs to. A boot-load failure and a genuine auth-behaviour regression are different owners, and today they produce the same job output — a red probe.

实测证据具体且有编号：run 34084559243 / job 101626009369，缺陷是启动时的一行：

AuthPlugin failed to load: The requested module '@better-auth/core/db'
  does not provide an export named 'createLocalAccountIssuer'

作业没有在那里退出，而是拿一台没有 auth 的服务器跑完了每一条 auth 与 CRUD 探针，最后挂在一条探针上。⇒ 本可以指名成因的那道扫描，跑在那些探针之后。

⭐ 而且它已经产生过可计量的代价：在 #16500 上让分诊席读了整份日志才够到根因。

不到 p1：CI 仍然见红（不是假绿），坏东西不会因此落地；代价是归因错误 + 一次全量日志阅读。

⛔ 一处不能被"修好"的东西

:984 那条模式里包含 Failed to register OIDC discovery routes —— 一条特例串。⚠️ 认领时若要重构这道扫描，⛔ 不要把它顺手清理掉（它显然是某次具体事故留下的），除非能确认它已被更一般的规则覆盖。

修法：卡面给的形状本席同意，并指出它为什么是"新断言"而非"机械编辑"

Scan the boot log for failed to load between the boot and the probes, and fail there with the plugin named. That is a new assertion on the smoke's contract, not a mechanical edit, which is why it is filed rather than carried into #16500's PR.

⇒ 两个改动缺一不可：

1. 位置：在 boot 与 probes 之间加一次检查（⛔ 不是把 section 4 整体前移 —— 那会让它在探针产生日志之前就跑完，丢掉它原本要抓的东西）；
2. 判据：按 failed to load 这类启动期信号匹配，⛔ 不是把 WARN 整体纳入 error 扫描（那会把每一条无害的 WARN 变成红）。

⭐ 且失败消息必须点名那个插件 —— 这正是本卡的目的（指认责任方），一条"boot 有问题"的通用红等于没修。

⛔ 不在本卡（卡面已划，本席保留）

• ⛔ Server is ready 该不该在降级启动时打印 ⇒ [finding] the server prints ✓ Server is ready on a degraded boot — the ready signal is independent of the degraded-capabilities warning, and the louder one is wrong #16630。
• ⛔ declared-range 那一半已在 main 上修好（fix(plugin-auth): pin the better-auth family to an exact 1.7.2, and gate the declared range against our own import surface #16634），guidance 那一半在 Registry canary failed: fresh npx create-objectstack install is broken #16500。

交给认领席

• ⚠️ 卡面的 run/job 编号与那条 boot 日志本席未复核（需要读 CI 归档）；本席确认的是 :974 / :984 两处源码事实（严重度与次序）。⇒ 认领时按那条 run 把日志调出来，它同时是回归 fixture：修好之后，同样的输入必须在 probes 之前就红，并点名 AuthPlugin。
• ⭐ section 4 自己的注释里写着它当初的意图："The Fresh projects: every auth endpoint returns 500 "Cannot set properties of undefined (setting 'modelName')" — fixed in 15.1.1 #3091 breakage announced itself at startup … and would have been caught by ANY error-level line." ⇒ 那句话对 Fresh projects: every auth endpoint returns 500 "Cannot set properties of undefined (setting 'modelName')" — fixed in 15.1.1 #3091 成立（那次记在 error 级），对这次不成立。修完之后把那句注释一并更新，否则又留下一段解释一个已不成立之前提的散文（本轮本席已处理过 [finding] Six test-file headers justify a pin's placement with "this package has no typecheck script (DEBT ledger entry)" — false for all three packages named; the DEBT ledger holds four other packages entirely #16742 / [finding] four docblocks attribute all 80 route registrations to this.routeManager.register( — false once #16243 lands, and one of the four is inside the census file that PR itself repaired #16307 / docs: two prose notes still describe PHASE2_IMPLEMENTATION.md sections 4 and 5 as teaching the unresolvable @objectstack/core/security subpath, which PR #16205 repaired #16208 三张同类）。

---

分诊席声明：本席只分类/定级/路由，⛔ 不认领、⛔ 不派工、⛔ 不写码、⛔ 不合并、⛔ 不裁决决策箱卡。

---

Generated by Claude Code