Skip to content

plugin-dev 的 analytics dev stub 仍会填满槽位,dispatcher 不检查 handlerReady —— #3891 退役 shim 后同形状的最后一处残留(dev-only) #4000

Description

@os-zhuang

按 Prime Directive #10 记录,#3891 / PR #3989 任务中发现的同类残留。

现象

#3989 退役了协议装配里的降级 analytics shim:槽位空 → /analytics/* 404、discovery 报 unavailable。但 dev 模式下这个语义会被 plugin-dev 重新破坏:

  • packages/plugins/plugin-dev/src/dev-plugin.ts:269createAnalyticsStub 在 dev 装配里注册 analytics 服务,把槽位填上;
  • 它按 D12 诚实自述(_dev: true → 归一化为 { status: 'stub', handlerReady: false }),discovery 层没问题;
  • 但 dispatcher 的 /analytics 域(packages/runtime/src/domains/analytics.ts)只判 getService('analytics') 真假,不读 handlerReady —— stub 存在就会被当真实现调用,返回 stub 数据 + 200。

这正是 #3891 修掉的形状("槽位被非真实现占住 → 200 + 假数据"),只是限定在显式 opt-in 的 dev 模式,严重性低得多——但 D12 的结论第 3 条写的是"Consumers treat only handlerReady: true / status: 'available' as a real capability",dispatcher 作为 consumer 并没有执行这一条。

修法(二选一)

  1. 删掉 dev analytics stub(倾向)。空槽位 404 现在本身就是诚实信号(fix(metadata-protocol,objectql)!: retire the degraded analytics shim — empty slot 404s instead of serving unscoped aggregates (#3891) #3989 之后 discovery 会如实报 unavailable),dev 模式下伪造一份 analytics 数据的价值存疑;真要在 dev 里用 analytics,装真引擎即可(@objectstack/service-analytics 支持 InMemory 策略)。
  2. dispatcher 域尊重 handlerReady: falsedomains/analytics.ts 解析服务后读 readServiceSelfInfohandlerReady === false 视同槽位空 → handled: false → 404。这条更通用(覆盖其他 dev stub 服务域),但改动面大——各域都要统一决定是否采纳。

若选 2,建议一并盘点其他 dev stub 服务域(storage / search / automation / realtime / notification / ai)是否同样被 dispatcher 当真实现调用。

关联:#3891#3989#3878、ADR-0076 D12。

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions