Skip to content

DriverPluginOptions 两个选项均为无效配置 —— serve.ts 传入的 datasourceName: 'telemetry' 从未注册过任何数据源 #4320

Description

@os-zhuang

#4251 的类型化清扫中发现(Prime Directive #10:范围外发现单独立 issue,不静默扩大 PR 范围)。

现状

DriverPlugin.start() 原有的数据源注册逻辑整体被 if (!metadata?.addDatasource) return; 守卫,而 addDatasource / getDatasources 在整个仓库中没有任何实现——metadata 槽的占用者 MetadataManager 从未提供过这两个方法,唯二引用就是这两个探测点本身。也就是说该分支在每一次启动中都提前返回,从未执行过。#4251 的 PR 已删除这段死代码(带类型的查找无法再表达对幻影方法的探测,这正是规则想要的效果)。

留下的问题:DriverPluginOptions 的两个选项(datasourceNameregisterAsDefault)配置的就是这段死代码,因此自始至终都是无效配置,但接口仍然对外声明它们。

受影响的真实调用点

packages/cli/src/commands/serve.ts:1008:

await kernel.use(new DriverPlugin(telemetry.driver, { datasourceName: 'telemetry', registerAsDefault: false }));

这个调用点相信自己注册了名为 telemetry 的数据源——实际从未发生。需要判断:遥测驱动是否需要真正的具名数据源可见性?若需要,现行路径应是 ADR-0062 的 DatasourceConnectionService + registerInMemory('datasource', …)(参见 DefaultDatasourcePlugin.registerVisibility),而不是复活 addDatasource

待决策(enforce-or-remove,同 ADR-0049 的思路)

  • remove:删除 DriverPluginOptions 两个成员(破坏性——serve.ts 的对象字面量会编译失败,需一并清理),changeset 写明 FROM → TO;或
  • enforce:让 DriverPlugin 通过现行的 declaration 路径真正兑现 datasourceName(需要论证 DriverPlugin 作为「测试与预构建/代理驱动的逃生舱」是否应当承担这个职责——DefaultDatasourcePlugin 的文档明确说它不再是 standalone 默认启动路径)。

倾向 remove:能力已由 ADR-0062 路径承接,DriverPlugin 保持纯粹的 driver 服务注册器。

备注

当前代码中 DriverPluginOptions 的 TSDoc 已标注 ⚠️ INERT 并指向本 issue;构造函数仍接受该参数(仅为源码兼容,不再存储)。

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