bug(plugin-auth): `[auth] no cache service registered` 在 CacheServicePlugin 注册前 21ms 就喊了 —— 误报，且把人引向「你需要 Redis」

[os-zhuang]

TL;DR

pnpm dev（showcase）每次启动都报一条"没有 cache 服务，限流退化成进程内内存计数器，多节点部署需要 Redis"。但 CacheServicePlugin 就在 21 毫秒后注册好了，而且它本来就在已加载插件列表里。

和 #4771 是同一类问题（校验/告警跑在提供方注册之前），但在另一个子系统，修法也不同，所以单开。

现场

WARN [auth] no cache service registered — rate-limit counters use a per-process in-memory
     store; a multi-node deployment needs a shared cache (Redis) to enforce limits
     globally (ADR-0069 D2)

启动摘要里的已加载插件：

Plugins: 47 loaded
         ObjectQL, SqlDriver, ..., QueueServicePlugin, CacheServicePlugin, SettingsServicePlugin, ...

证据

--log-level info 的时间戳：

事件	时刻
WARN [auth] no cache service registered	04:28:04.527
INFO Service 'cache' registered {"service":"cache"}	04:28:04.548
INFO CacheServicePlugin: registered memory cache adapter	04:28:04.548

差 21ms。

为什么值得修

告警本身的建议（"多节点需要 Redis"）在这个语境下是错的指路：这个部署确实配了 cache 插件，缺的不是 Redis，是"auth 在 cache 注册完之前就问了"。照着这条日志去接 Redis，接完还是会看到同一条 warn。

同 #4771：真正没配 cache 服务的部署会得到一模一样的一条 warn，两种情况无法区分。

修法（择一）

1. 把这次探测推迟到 kernel:ready，那时服务注册表才是完整的 —— 与 bug(service-automation): flow 节点类型校验跑在插件贡献的执行器注册之前 —— 每个 ADR-0019 approval flow 都被误报「will fail at execution time」 #4771 同一思路。
2. auth 改成惰性解析 cache：不要在 start() 时一次性拍板并缓存"没有 cache"，而是在真正用限流计数器时再取一次服务。这样也顺带修掉真正的功能退化 —— 目前即使 cache 后来注册上了，auth 这一侧是不是还捏着启动时那个进程内存储？这一点我没验证，但如果是，那就不只是日志误报，而是限流真的没用上共享 cache。值得在修的时候一并确认。

复现

rm -rf examples/app-showcase/.objectstack && pnpm dev

看时序：objectstack dev --seed-admin --log-level info，对比上表两个时间戳。

[os-zhuang]

认领:PM 循环第 3 轮
会话:session_015Br2xsJsczFsTR9bvbh2Ny
分支:claude/issue-4772-auth-lazy-cache-resolve
Worktree:objectstack-issue-4772

分诊:落地 objectstack(后端);PM 裁定取修法 2(惰性解析 cache),不取修法 1。

这里我和 #4771 走了不同的方向,理由是两者的风险面不同:

• 长远合理性 —— 修法 1(把探测推迟到 kernel:ready)只修日志。issue 自己指出了一个尚未证实的真降级:auth 在 start() 时一次性拍板「没有 cache」并缓存,那么即使 cache 随后注册上,限流这一侧是不是还捏着启动时那个进程内 store?如果是,这就不是误报,而是限流真的没用上共享 cache —— 多节点部署的限额从未被全局强制过,而日志还在告诉你「去接 Redis」。惰性解析同时关掉日志误报和这个功能洞;修法 1 只关掉前者,并且会让后者更难被发现(告警没了,人就不看了)。
• 防 AI 写错 —— 「宽容消费端」正是 AI 批量犯错被掩盖的温床:启动期取不到服务就静默退化成本地实现、然后永久保持,是这条反模式的教科书形态。惰性解析把「取服务」放回真正用到的那一刻,让声明的能力(共享限流)在运行时真正兑现。

要求 dev 先验证再修:确认 start() 缓存的 cache 句柄是否真的一直被后续限流计数使用。这是决定本 issue 是「日志误报」还是「安全相关的功能洞」的分水岭 —— 结论请写进 PR 描述与报告。若证实是功能洞,顺手在 issue 上补 security 标签的建议一并说明。

保留一条告警:当限流计数真正要用 cache 而此刻确实没有时,才喊 —— 那时它才是真信号。

维护者可否决本裁定;不阻塞派发。

---

Generated by Claude Code

[os-zhuang]

交叉链接:本 issue 与 #4769、#4771 是同一个形状在三个互不相干子系统里的三次独立发作。已立决策单 #4776(是否收紧 kernel 注册表契约,让「尚未知道」在类型上不等于「没有」),附两轴分析。

本 issue 的修复照常进行,不受阻塞。另:你被要求验证的那一点(auth 是否一直捏着启动时的进程内 store)对 #4776 的判断很关键 —— 如果证实是真功能洞,那它就是这一类缺陷「不止是日志噪音」的第二个实证(第一个是 #4769 把假证据写进了持久层)。请务必把结论写清楚。

---

Generated by Claude Code