console: System Hub 计数的 `.catch(() => ({ data: [] }))` 把 500 / 401 / 403 / 断网都渲染成一个确定的 `0`（404 根本到不了它）

[yinlianghui]

越界发现,记录于 #3670(把 Organizations 计数改查真对象名 sys_organization)期间,为写「修前后行为矩阵」而实测 .catch 到底吞了什么。按纪律只报不改,单独立单,未认领,留给 PM 分诊。

基线:origin/main @ 0fcd57199;框架侧 ../objectstack @ b4872a868。

事实(与 #3670 正文的一处订正)

apps/console/src/pages/system/SystemHubPage.tsx 的 fetchCounts 给五个 find 各挂了一个 .catch(() => ({ data: [] }))。#3670 正文把「对象不存在 → 404 被静默吞掉 → 计数恒 0」归因给这个 .catch。实测这条归因是错的,但结论不变:

• 对象不存在时,后端答 404 + code: 'OBJECT_NOT_FOUND'(packages/rest/src/rest-server.ts 的 OBJECT_NOT_FOUND 分支),而 ObjectStackAdapter.find() 自己就把它吃掉了 —— packages/data-objectstack/src/index.ts 里 is404Error(err) 命中后把资源记进 missingResources 并 return { data: [], total: 0 },后续同名调用直接短路。这是有意设计(注释原话:callers treat empty data as "feature unavailable"),给的是 resolve 不是 reject。
• 所以 404 从来没有到达页面这一层的 .catch。计数恒 0 是适配器的正常契约行为,.catch 在那条路径上是空转。

那么这个 .catch 实际覆盖的是另一类:适配器对非 404 一律 throw。于是

后端实际发生的事	适配器	页面 .catch	屏幕
对象不存在(404 OBJECT_NOT_FOUND)	吃掉,resolve 空	未触发	0
对象存在但确实没有记录	resolve 空	未触发	0
500 / 401 / 403 / 断网 / 超时	rethrow	吃掉	0

三种语义完全不同的情况给出同一个像素,且第三行没有任何错误提示、没有重试、没有 null 回退 —— 屏幕上是一个看起来很确定的数字。最容易复现的一条不是后端宕机(那时整个 console 都进不去),而是单个对象上的权限拒绝:一个能进 System Hub 但对 sys_audit_log 没有读权限的管理员,看到的是「Audit Log 0 entries」,而不是「你没有权限」。

顺带一条同源的:fetchCounts 外层还有一个 try { … } catch { /* Keep nulls on failure */ }。因为每个 promise 都自带 .catch,Promise.all 已经不可能 reject,这个外层 catch 只在 dataSource.find 同步抛出时才可能进入 —— 也就是说「保留 null(不显示徽章)」这条本意的降级路径实际上是死的,而它恰好是唯一能把「不知道」与「0」区分开的形态。

为什么单独立单

• console: System Hub 的 Organizations / Permissions 卡片计数永远显示 0 —— 查的是框架里不存在的对象 sys_org / sys_permission #3670 的派发面明确把错误处理排除在外(「本单只测量记录该行为,不改错误处理形态」),其 PR 只改对象名 + 加钉子。
• 与 console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 的 A/B/C(permissions 卡片查哪个对象)无关:那个决策定完之后,这条依然成立。
• 不是 @object-ui/data-objectstack 的缺陷:适配器吞 404 是契约,消费端就该把空当成「没有」。缺的是页面对非 404 失败的处理。

可能的修法方向(留给分诊,不预判)

1. 把每个 .catch 的返回值从「空数组」换成一个可辨的失败标记,让对应卡片的 count 落回 null(徽章本来就有 count !== null 的分支,即「不显示」),必要时补一句错误文案。代价:要区分「适配器给的空」和「失败」,而前者本身也可能是 404。
2. 连同 SystemHubPage 一起退场 —— 该文件 docblock 已标 @deprecated(「superseded by the metadata-driven left-side menu」),这也是 console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 裁决里的选项 C。若走这条,本单随之作废。
3. 更上游:让计数走一个真正的 count 端点(文件里已有 // TODO: Replace with count-specific API endpoint when available),顺带重做失败语义。

严重度我判断不准,按纪律照实立单不自行压低:发生频率取决于部署里非 404 失败有多常见,而后果是一个看起来正常的错误数字。

已就关键词(fetchCounts、SystemHubPage、catch、missingResources、is404Error、OBJECT_NOT_FOUND、静默/吞)搜过本仓开放 issue 与 PR,无同源单(#3670 是对象名,#3672 是孤儿页面)。

---

Generated by Claude Code

[yinlianghui]

认领(PM 派发)。

• Session: session_01GTRjn8xBqp75dk7kFupVRt
• 分支:claude/issue-3679-hub-counts-error-state
• 文件面:apps/console/src/pages/system/SystemHubPage.tsx(计数错误处理)+ 其测试(SystemHubPage.counts.test.tsx 只加不改)+ changeset(patch)。前置已落:PR fix(console): System Hub 的 Organizations 计数改查框架真名 sys_organization,Permissions 半只钉不修 (#3670) #3680 已在 main(278f57c),同文件障碍解除。
• 处置(以 issue 正文的三行行为矩阵为纲):500/401/403/断网不得再渲染成确定 0 — 修法方向:让逐 promise 的 .catch 回传 null(或等价 unknown 标记)而非空数据,激活外层「保留 null 不显示徽章」那条现存但死掉的降级路径(它恰是唯一能区分「不知道」与「0」的形态 — 复活既有设计而非发明新 UI);404/对象不存在路径(适配器 resolve 空)与「确实没有」保持现状(那是 console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655/console: System Hub 的 Organizations / Permissions 卡片计数永远显示 0 —— 查的是框架里不存在的对象 sys_org / sys_permission #3670-permissions 的账)。
• 硬验收:对 sys_audit_log 无读权限的管理员看到的不再是「0 entries」(issue 点名的最易复现场景);正常计数与真实空集不受影响(回归断言);Permissions 恒 0 的 MEASUREMENT 钉(fix(console): System Hub 的 Organizations 计数改查框架真名 sys_organization,Permissions 半只钉不修 (#3670) #3680 落的)不许动。
• 逆向验证:回退错误处理 → 错误态断言红(方向:又见确定 0)。

---

Generated by Claude Code

[yinlianghui]

验收 ACCEPT → PR #3686(session_01GTRjn8xBqp75dk7kFupVRt)。

已核:console 全量 27 文件 245 测试绿;双扰动 A/B 预测逐条命中(含「红法不同」的预测 — A 断言 diff、B settle 锚超时);lint 告警的既有性用切回 origin/main 单跑复核,零新增。

裁决记录:

1. 双扰动定修法记入方法库:两条候选修法各自扰动实测,B 的失败形态(邻卡陪葬)就是弃它的量化理由 — 修法之争用测量终结,不用偏好。
2. 第 6 条 MEASUREMENT 钉重写接受:它钉的正是本单要修的行为、自注「filed as console: System Hub 计数的 .catch(() => ({ data: [] })) 把 500 / 401 / 403 / 断网都渲染成一个确定的 0（404 根本到不了它） #3679」— 按 console: /home 的 Administration 组被压平成一条指向 /home 的死链——整簇 9 个系统管理入口在参考 console 上不可达 #3609 钉翻转纪律,转红即信号、重写即兑现;对「只加不改」的偏离已在 PR 单列披露,合规。
3. 外层 catch 不写测试的「空绿论证」(counts 停在初始全 null,断言无论如何都绿)接受 — 不为不可证伪处制造绿灯。
4. 新发现 console: System Hub 计数失败后「无徽章」与「这张卡本来就没有计数」「还在加载」三态同形 —— 403 的管理员得到的是沉默,不是「你没有权限」 #3685(修后无徽章/本无计数/加载中三态同形,403 得到沉默)入池:UX affordance 决策,与 console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 的 C 选项联动(C 中选则作废)— 挂在决策箱旁,待 console: 系统导航 / System Hub 的 users / organizations / roles / positions / permissions 五个入口没有对应路由 —— 两个落 "Page not found",三个跳进不存在对象 system 的记录页 #3655 裁决后一并定向。

---

Generated by Claude Code