Skip to content

packages/rest 的 14 个 getDiscovery 测试替身返回 endpoints,一个真实生产者从未发过、且已在 #4828 退役的键 #5674

Description

@os-zhuang

发现于 #4828 的实施(界外发现,查重无命中故新开;未认领;observation-class,今天没有用户会撞上)。

现象

packages/rest/src/ 下 14 个测试文件的 getDiscovery mock 长这样:

getDiscovery: vi.fn().mockResolvedValue({
  version: 'v0',
  endpoints: { data: '', metadata: '', ui: '', auth: '/auth' },
}),

但真实的 getDiscovery()(packages/metadata-protocol/src/protocol.ts)发的是 routes,从来没有发过 endpointsendpoints 只在 dispatcher 那条路径上存在过(作为 routes 的逐字副本),而 #4828 已按 ADR-0049 把它删除。

从键名看(data/metadata/ui/auth),这些替身本意就是 routes,只是拼错了对象。

为什么今天没事,以及为什么仍值得记一笔

rest-server.ts 的 discovery handler 读的是 discovery.routes,所以这些替身的 endpoints 是惰性的:if (discovery.routes) 为假,整个 routes 增补块被跳过。测试断言的是别的东西,一直是绿的。

值得记一笔的原因有两个:

  1. 它们是唯一还在拼写已退役键的地方。下一个写 rest 测试的人照抄这个替身,退役键就在 fixture 层复活了;
  2. 它们让替身描述了一个从未存在过的生产者形状,削弱了这些测试作为「REST 层在真实上游之上做了什么」的证据力。

为什么 #4828 没有顺手改

改成 routes: {...} 会把 if (discovery.routes) 从假翻成真,让 handler 开始执行路由增补(包括 probeMcpServeable),这是行为变更,14 个文件的既有断言需要逐个复核。#4828 的范围是生产者的线上形状,不是 fixture 保真度,所以按 Prime Directive #10 记在这里而不是扩大那个 PR。

修的时候建议一次一个文件,确认每个文件的断言在 routes 块真的执行之后依然成立。

参考:#4828

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions