[RETRACTED — not a regression] cloud service-ai embedder failure was a local build artifact, not f1a8114

[os-zhuang]

Found while bumping cloud's framework pin for the #3624 follow-up. Currently live on framework main.

症状

cloud 的 @objectstack/service-ai 有一个测试断言:配置了 provider 时,embedder 会经由 EMBEDDER_SERVICE 构建并注册。对着 framework main 跑,它红了:

FAIL  src/__tests__/ai-service.test.ts > AIServicePlugin > embedder binding
      > builds and registers embedder via EMBEDDER_SERVICE when provider is configured

AssertionError: expected undefined to be defined
 ❯ src/__tests__/ai-service.test.ts:2059:26
    2057|  const services = ctx.getServices();
    2058|  const embedder = services.get('embedder') as any;
    2059|  expect(embedder).toBeDefined();

同一个测试文件里还打了一行:[AI] Metadata service not available: Service "metadata" not found。

二分结果

同一份 cloud 工作副本、同一份 node_modules,只切换 framework 构建:

framework SHA	@objectstack/service-ai
bc17d39 (#3647 合入点)	✅ 563 passed (44 files)
ce1f100 (当时的 main 顶端)	❌ 1 failed / 562 passed

区间里只有两个提交:

• f1a8114 — fix(client,service-i18n): ledger the autonomous service-mount surface; two i18n SDK calls reached nothing (#3636) (#3646)
• ce1f100 — fix(rest): emit the projected export header on an empty result set (#3547) (#3649)

首要嫌疑是 f1a8114。 失败的正是"服务是否被注册/挂载"这件事,而那个提交改的就是 autonomous service-mount 的登记方式;ce1f100 只动 REST 导出表头,与服务注册无关。我没有为区分这两个再跑一次完整 framework 构建,所以这一条是强推断而非已验证的二分终点 —— 谁接手可以只构建 f1a8114 来钉死。

为什么 framework CI 没抓到

embedder / EMBEDDER_SERVICE 的这条注册路径由 cloud 的 @objectstack/service-ai 覆盖,framework 仓库里没有对应测试。cloud CI 又把 framework 钉在 .objectstack-sha(当时是 6ba3788),所以直到有人抬 pin 才会撞上 —— 也就是现在。

影响

任何把 framework pin 抬过 f1a8114 的 cloud 升级都会红。#3624 的 cloud 侧跟进 PR 因此刻意只把 pin 抬到 bc17d39(最小、且已验证干净),而不是 main 顶端 —— 抬到顶端就会连带吞下这个回归。

建议

1. 确认 f1a8114 是不是真凶(单独构建那个 SHA 跑 cloud 的 service-ai)。
2. 修 framework 侧的注册,或修正 cloud service-ai 对新 mount 契约的用法 —— 取决于哪一边才是对的。
3. 考虑把这条注册路径在 framework 侧也补一个测试,否则同类回归还会以同样的方式(只有抬 pin 时才暴露)再来一次。

Refs #3624, #3647, #3646。

[os-zhuang]

撤回:上面的二分结论是错的,f1a8114 和 ce1f100 都是清白的

我把二分跑完了,结果推翻了原帖。补做的两次干净全量构建:

framework SHA	@objectstack/service-ai
bc17d39	✅ 563 passed
f1a8114(原帖点名的"首要嫌疑")	✅ 563 passed
ce1f100(区间另一个提交)	✅ 563 passed

区间里只有这两个提交,两个都过。所以 bc17d39 → ce1f100 之间不存在回归,原帖那张表里 ce1f100 那一行不成立。

真实原因

原帖的失败是我本地的构建产物不一致造成的,不是源码。出问题的那次,framework 侧指向的 worktree 经历了一串交错的部分重建 —— 期间为了做修复的反向验证,我用 OS_SKIP_DTS=1 单独重建过 platform-objects 和 plugin-auth 两次,夹在几次全量构建之间。对着同一个 SHA 做一次干净的 pnpm install && turbo run build 之后,service-ai 就是 563 全过。

换句话说:我拿一个半新半旧的构建产物去指控源码提交。 f1a8114 的作者不欠任何解释 —— 抱歉。

影响面

• framework main 没有这个回归,cloud 抬 pin 不需要绕开 f1a8114。
• cloud#885 的 pin 选择和它的 commit message 引用了这个不存在的回归,我正在改正。
• 这个 issue 应当关闭为 not planned(非缺陷)。原帖里唯一仍然成立、也仍然值得做的一点是最后那条建议:embedder / EMBEDDER_SERVICE 这条注册路径目前只有 cloud 的 service-ai 覆盖,framework 侧没有对应测试。 那是个真实的覆盖缺口,只是与本次误报无关 —— 如果要跟进,值得单开一个 issue,而不是留在这个已被推翻的帖子里。

---

Generated by Claude Code