发现于 #4828 的实施(界外发现,查重无命中故新开;未认领)。
现象
#4828 把 dispatcher 的顶层 features 正名为 capabilities 之后,两个 discovery 生产者都发 capabilities 了 —— 但填的键集互不相交:
| 生产者 |
capabilities 的键 |
getDiscovery()(packages/metadata-protocol,REST /discovery 的上游) |
comments、automation、cron、search、export、chunkedUpload、transactionalBatch —— 即 WellKnownCapabilitiesSchema 的成员 |
getDiscoveryInfo()(packages/runtime/src/http-dispatcher.ts,/.well-known/objectstack) |
search、websockets、files、analytics、ai、notifications、i18n |
只有 search 是两边都有的。
而 SDK 侧 packages/client/src/index.ts 的 getter:
get capabilities(): WellKnownCapabilities | undefined {
const raw = this.discoveryInfo?.capabilities;
...
return result as unknown as WellKnownCapabilities;
}它把结果断言成 WellKnownCapabilities。所以面对 dispatcher 供的 discovery,client.capabilities.transactionalBatch 的静态类型是 boolean、运行时是 undefined —— 类型在说谎。comments / cron / export / chunkedUpload 同理。
DiscoverySchema.capabilities 本身是开放的记录类型,所以两边都合法,schema 不会红。
为什么不在 #4828 里一起修
#4828 的裁定是「正名取 capabilities」,没有裁定两个生产者的能力词汇表该不该统一 —— 那是一个新的契约决策(要么让 dispatcher 也按 WellKnownCapabilities 词汇表作答,要么承认两套词汇并在 schema 里把它表达出来,要么让 SDK 的 getter 不再撒这个类型谎)。#4828 只是把分裂从「一个发 features 一个发 capabilities」收敛成「都发 capabilities」,分裂的深度减小了但没有消失。
需要说明的是:这不是 #4828 引入的回归。在此之前 dispatcher 完全不发 capabilities,client.capabilities 对 dispatcher 宿主返回的是 undefined(每个标志位都拿不到)。#4828 之后至少 search 等 7 个键有了真实答案。只是分歧现在更容易被看见,也更容易被误用。
决策点(需要维护者定,不要猜)
- dispatcher 是否应当按
WellKnownCapabilities 词汇表作答?它没有 engine/registry 访问权,算不出 comments(需要 sys_comment 对象)和 transactionalBatch(需要 engine.transaction),所以「照搬」并不现成。
- 还是承认「能力词汇随生产者而不同」,并把这一点写进
DiscoverySchema.capabilities 的声明与文档,同时把 SDK getter 的返回类型改成诚实的(部分可用)形状?
任一方向都会改动公开契约形状,故不猜。
发现于 #4828 的实施(界外发现,查重无命中故新开;未认领)。
现象
#4828把 dispatcher 的顶层features正名为capabilities之后,两个 discovery 生产者都发capabilities了 —— 但填的键集互不相交:capabilities的键getDiscovery()(packages/metadata-protocol,REST/discovery的上游)comments、automation、cron、search、export、chunkedUpload、transactionalBatch—— 即WellKnownCapabilitiesSchema的成员getDiscoveryInfo()(packages/runtime/src/http-dispatcher.ts,/.well-known/objectstack)search、websockets、files、analytics、ai、notifications、i18n只有
search是两边都有的。而 SDK 侧
packages/client/src/index.ts的 getter:它把结果断言成
WellKnownCapabilities。所以面对 dispatcher 供的 discovery,client.capabilities.transactionalBatch的静态类型是boolean、运行时是undefined—— 类型在说谎。comments/cron/export/chunkedUpload同理。DiscoverySchema.capabilities本身是开放的记录类型,所以两边都合法,schema 不会红。为什么不在 #4828 里一起修
#4828 的裁定是「正名取
capabilities」,没有裁定两个生产者的能力词汇表该不该统一 —— 那是一个新的契约决策(要么让 dispatcher 也按WellKnownCapabilities词汇表作答,要么承认两套词汇并在 schema 里把它表达出来,要么让 SDK 的 getter 不再撒这个类型谎)。#4828 只是把分裂从「一个发features一个发capabilities」收敛成「都发capabilities」,分裂的深度减小了但没有消失。需要说明的是:这不是 #4828 引入的回归。在此之前 dispatcher 完全不发
capabilities,client.capabilities对 dispatcher 宿主返回的是undefined(每个标志位都拿不到)。#4828 之后至少search等 7 个键有了真实答案。只是分歧现在更容易被看见,也更容易被误用。决策点(需要维护者定,不要猜)
WellKnownCapabilities词汇表作答?它没有 engine/registry 访问权,算不出comments(需要sys_comment对象)和transactionalBatch(需要engine.transaction),所以「照搬」并不现成。DiscoverySchema.capabilities的声明与文档,同时把 SDK getter 的返回类型改成诚实的(部分可用)形状?任一方向都会改动公开契约形状,故不猜。