发现于 #4016 实施过程中,故意留在那个 PR 之外:删它是对「不合规后端」的行为变更,不属于「把请求搬到新路径」这件事。未认领。
现状
packages/data-objectstack/src/metadata-client.ts 的 layered() 在 200 之后有一段容忍分支(变量名 hasEnvelope):当 body 里 code / overlay / effective一个都没有时,把整个 body 塞进 effective 返回。
这段兜底的唯一生产者是已弃用的那个查询标记:老拼法在后端 protocol 实现没有 getMetaItemLayered 时会下坠到普通条目读,答 { type, name, item } 信封,于是消费侧需要容忍。
为什么现在不可达
迁到 GET /meta/:type/:name/layers 之后,同样情形上游是明确拒答的 —— framework origin/mainpackages/rest/src/rest-server.ts 新路径挂载处:协议实现缺 getMetaItemLayered 时返回 501 NOT_IMPLEMENTED,注释写明「A dedicated path cannot fall through to the plain read the way the flag did … would be answering a different resource」。501 走 !res.ok,在 layered() 里抛错,到不了这段兜底。
其余 200 分支都由 GetMetaItemLayeredResponseSchema 约束(code / overlay / effective 都是必填键),所以合规服务端答的 200 恒满足 hasEnvelope。
建议
上游关掉 ?layers= 弃用窗口(硬切时机归维护者)后,连同这段兜底一起删,并把「501 抛错」这条钉在测试里(#4016 的 PR 已经钉了 501 抛错,所以删除时不会失去覆盖)。在窗口关掉之前删也可以,但那就要单独论证「不合规后端」的期望行为,不是白捡的清理。
观察类(finding,不进派发池):今天没有用户能触到这段代码 —— 它是休眠分支,不是缺陷。
发现于 #4016 实施过程中,故意留在那个 PR 之外:删它是对「不合规后端」的行为变更,不属于「把请求搬到新路径」这件事。未认领。
现状
packages/data-objectstack/src/metadata-client.ts的layered()在 200 之后有一段容忍分支(变量名hasEnvelope):当 body 里code/overlay/effective一个都没有时,把整个 body 塞进effective返回。这段兜底的唯一生产者是已弃用的那个查询标记:老拼法在后端 protocol 实现没有
getMetaItemLayered时会下坠到普通条目读,答{ type, name, item }信封,于是消费侧需要容忍。为什么现在不可达
迁到
GET /meta/:type/:name/layers之后,同样情形上游是明确拒答的 —— frameworkorigin/mainpackages/rest/src/rest-server.ts新路径挂载处:协议实现缺getMetaItemLayered时返回 501NOT_IMPLEMENTED,注释写明「A dedicated path cannot fall through to the plain read the way the flag did … would be answering a different resource」。501 走!res.ok,在layered()里抛错,到不了这段兜底。其余 200 分支都由
GetMetaItemLayeredResponseSchema约束(code/overlay/effective都是必填键),所以合规服务端答的 200 恒满足hasEnvelope。建议
上游关掉
?layers=弃用窗口(硬切时机归维护者)后,连同这段兜底一起删,并把「501 抛错」这条钉在测试里(#4016 的 PR 已经钉了 501 抛错,所以删除时不会失去覆盖)。在窗口关掉之前删也可以,但那就要单独论证「不合规后端」的期望行为,不是白捡的清理。观察类(
finding,不进派发池):今天没有用户能触到这段代码 —— 它是休眠分支,不是缺陷。