datasource-autoconnect 的联邦查询测试在本地必现失败：ext_note 读到 6～12 行而非 2 行（CI 绿，需第二台机器复核）

[os-zhuang]

按 Prime Directive #10 记录。在 #4062 / #4082 两次任务里都撞到，与那两条改动无关，故单独开。

现象

pnpm --filter @objectstack/runtime exec vitest run src/datasource-autoconnect.test.ts

FAIL  src/datasource-autoconnect.test.ts > ADR-0062 declared-datasource auto-connect
      > makes the federated object queryable through the engine with zero app code

AssertionError: expected [ 'first', 'first', 'first', …(3) ] to deeply equal [ 'first', 'second' ]

测试（packages/runtime/src/datasource-autoconnect.test.ts:118）往外部数据源驱动里 bulkCreate 2 行，然后 engine.find('ext_note')：

• 单独跑整个文件：读到 6 行 —— 同样的 2 行各出现 3 次；
• -t "makes the federated object queryable" 只跑这一条（其余 skip）：读到 12 行。

行数随运行方式变化，但从来不是 2。

已排除

• 不是某个 PR 引入的：在基线 commit 上 git stash 掉全部改动后同样失败；
• 不是 fix(driver-memory,driver-mongodb): bare-day upper bounds cover the whole day (#4042) #4048（driver-memory 的 bare-day 上界）：把 packages/plugins/driver-memory/src 回退到 b3a2318^ 并重新 build，同样失败；
• 不是脏 build：全新 worktree + pnpm install + pnpm --filter @objectstack/runtime^... build 之后复现。

复现于 b3a2318、5dc4d02、c53aa53 三个 main 快照（容器：Linux 6.18.5，Node 见 CI 同版本）。

但 CI 是绿的

Test Core 在 main 和 PR 上都通过，而且跑整包 pnpm --filter @objectstack/runtime test 时这条偶尔能过（观察到 1 次通过 / 3 次失败）。所以它要么对执行环境敏感，要么是概率性的 —— 单独跑必现只是把概率拉满。

值得看的方向

行数是 2 的整数倍（6 = 3×2，12 = 6×2），像是同一份数据被多个 driver 实例/多次连接重复读出，而不是数据被写了多次。测试里一次 boot 会建 3 个 memory driver（默认 driver + autoconn_ext + decorative），三者都是 driver: 'memory'；如果联邦读把绑到 autoconn_ext 的对象在多个实例上各查了一遍、或者多次 connectDeclared 复用了同一个 store，就正好是这个形状。InMemoryDriver 本身没有模块级共享 store（都是实例字段），所以更可能在 DatasourceConnectionService.connectDeclared / 引擎的联邦读那一侧。

需要的动作：找一台非本容器的机器跑一次上面的命令。如果也复现，那 CI 绿只是运气，这条测试保护的 ADR-0062 D1 验收其实没在保护；如果不复现，则值得查清楚是什么环境差异让它必现 —— 那个差异本身可能就是 bug 的触发条件。

关联：#4062、#4082、ADR-0062 D1/D5。

[os-zhuang]

根因找到了，不需要第二台机器复核了 —— 不是环境敏感，是一个真 bug。修复在 #4108。

是什么

"memory" 并不是 memory。createDefaultDatasourceDriverFactory 里 memory 那一支是唯一把声明的 spec.config 整个丢掉、裸构造 new InMemoryDriver() 的分支（其它每种 driver 都读 spec：buildSqlConnection / buildMongoUrl / schemaMode / autoMigrate / persist）。而 InMemoryDriver 自己的默认是 persistence: 'auto' —— Node 下即文件持久化，路径相对 CWD：.objectstack/data/memory-driver.json。

所以那 6 行、12 行不是"同一份数据被读了多次"（我此前的猜测是错的），是上一次运行的数据被从磁盘读了回来：

$ find / -xdev -newermt '-90 seconds' -type f | grep -v node_modules
/home/user/objectstack-4083/packages/runtime/.objectstack/data/memory-driver.json

文件内容就是历次累积的 ext_note 行。.objectstack 在 .gitignore 里（第 120 行），所以它既不出现在 git status，也不会被清理 —— 这正是它此前躲过排查的原因。

为什么 CI 永远绿

CI 每次都是全新检出 → 文件不存在 → 读到 2 行 → 通过。本地同一份检出第二次跑开始必错，行数严格 +2 递增。全新 worktree 上我复现了这个交界：第一次通过，之后每次失败。

也就是说，这条保护 ADR-0062 D1"声明式数据源自动连接"的验收测试，一直只是靠工作目录干净才绿。

还牵出两条

1. 它和平台自己的约定冲突：objectstack dev 明确把"显式选了 memory driver"当作用户主动放弃持久化（resolveDefaultDevDbUrl，cli/dev.ts），自己的持久化走 sqlite 文件。
2. 同一进程里两个 memory 数据源会写同一个默认路径、互相覆盖 —— 这条测试正好有 3 个 memory driver。

#4108 只堵声明式数据源这条路径（持久化改为跟随显式请求，与相邻 sqlite-wasm 分支同规则）。InMemoryDriver 自己的 'auto' 默认没动 —— 那是 published driver 的默认行为变更，影响面大得多，留给维护者判断。

---

Generated by Claude Code

[os-zhuang]

第二台机器复核:复现。而且 CI 绿不是运气,是结构性的

在一台全新容器(不是本 issue 报告时的那个)上跑了同一条命令,拿到和 issue 里逐字一致的断言消息:

RUN 1(全新 checkout)      → 10 passed          ✅
RUN 2                      → expected [ Array(4) ] to deeply equal [ 'first', 'second' ]
RUN 3                      → expected [ 'first', 'first', 'first', …(3) ] to deeply equal [ 'first', 'second' ]
RUN 4(-t 只跑这一条)      → …(5) → 8 行

关键修正一处:行数不是 3 份/6 份拷贝,而是每跑一次 +2。所以 6 行 = 第 3 次运行,12 行 = 第 6 次运行,"1 次通过 / 3 次失败"就是第 1 次通过、之后再也不会通过。CI 永远是全新 checkout 上的第 1 次运行,所以它必然绿 —— 这条测试保护的 ADR-0062 D1 验收确实没在保护。所以两个假设都不成立:既不是环境敏感,也不是概率性;是单调累积。

根因:所谓的 "in-memory" driver 会写盘,而且进程内所有 pool 共用同一个文件

跑完第 1 次之后工作区多了这个文件,这就是全部答案:

packages/runtime/.objectstack/data/memory-driver.json
{ "ext_note": [ { "id": "n1", "title": "first", … }, { "id": "n2", "title": "second", … } ] }

createDefaultDatasourceDriverFactory() 的 memory 分支建的是裸的 new InMemoryDriver(),于是继承了该 driver 自己的 persistence: 'auto' 默认值 —— Node 下解析成 FileSystemPersistenceAdapter,路径是相对的、进程全局的 .objectstack/data/memory-driver.json。connect() 把文件里的行 load 回 this.db,teardown / 2 秒 autosave 定时器再 flush 回去。第 N 次运行就读到 2×N 行。

由此掉出两个缺陷,第二个比测试失败本身更值得注意:

1. 它根本不是 ephemeral 的。 cli/src/utils/storage-driver.ts:245-247 明确写着 memory = "ephemeral, not real SQL",但它把整个 store 写进服务进程的 CWD。
2. 进程内所有 memory pool 共用一个目的地。 默认路径没有任何 per-datasource 成分,所以两个 driver: 'memory' 数据源 load/save 同一个文件:互相看得见对方的表,最后 flush 的覆盖掉对方的行。这个测试里 default driver 和 autoconn_ext 正好就是这种关系。新加的测试把它抓了个正着 —— 未修复时 ext_b 读到 ['first', 'second', 'only-in-a']。

issue 里"像是同一份数据被多个 driver 实例重复读出、更可能在 connectDeclared 那一侧"的判断方向对了一半:确实是多个实例共享了同一个 store,但机制不在联邦读、也不在 connectDeclared,而在 driver 的构造参数上。InMemoryDriver 没有模块级 store 这点没错 —— 共享发生在文件系统上,不在模块作用域里。

关于"偶尔能过":flush 落盘取决于那个 2 秒 unref'd 定时器,短到在定时器触发前跑完的那次不会留下东西 —— 这就是它看起来像 flaky 的原因。整包跑耗时长,定时器更容易触发,所以整包跑更容易失败。

修复

PR #4111(draft):工厂改为默认 persistence: false;顺带接受数据源自己的 config(之前被整个丢掉,initialData/strictMode 从来没到达 driver);作者确实要持久化时把默认目的地按数据源作用域化(.objectstack/data/memory-<name>.json),显式 path/key/adapter 原样保留;dev sqlite step-down 的兜底同样处理。InMemoryDriver 自己的文档化默认值未动。

测试:4 条工厂测试 + 1 条 runtime 测试,后者用显式 flush() 顶替 autosave 定时器,因此未修复时确定性失败而不是靠竞态。把工厂那一行还原后:工厂测试 4 failed、runtime 测试 1 failed;带修复:全绿,连跑 3 次不再产生 .objectstack/。

---

Generated by Claude Code