Skip to content

datasource-autoconnect.test.ts federated-query case fails locally on clean main — engine.find returns 8 duplicated rows for 2 seeded (CI green, so likely environment-sensitive) #4102

Closed as duplicate

Description

@os-zhuang

Hit while running the @objectstack/runtime suite for unrelated work. Filing rather than chasing it, since it is not mine and not obviously broken for everyone.

Symptom

packages/runtime/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', …(5) ] to deeply equal [ 'first', 'second' ]

The test seeds exactly two rows into the live external driver and reads them back through the engine:

await driver.bulkCreate('ext_note', [{ id: 'n1', title: 'first' }, { id: 'n2', title: 'second' }]);
const rows = await engine.find('ext_note');
expect(rows.map((r) => r.title).sort()).toEqual(['first', 'second']);

engine.find returns eight rows, and the sorted head is all 'first' — so the federated read is multiplying rows rather than returning the two that were written.

Reproduction / scoping

  • Clean main at 7ac1995, fresh full pnpm build, node v22.22.2.
  • Fails both in the full package suite (1 failed | 913 passed) and when the file is run alone (1 failed | 9 passed), so it is not cross-file order pollution.
  • Reproduces with unrelated local edits stashed, so it is not caused by them.

Important caveat

CI's Test Core job was green on #4084 against this same base, so this does not reproduce everywhere — it is likely sensitive to something environmental (driver/adapter build, platform, or a timing assumption in the federated read path) rather than plainly broken on main. Worth someone confirming whether the runtime suite's datasource-autoconnect case is actually in CI's scope, because if it is and it passes there, the row multiplication is real but conditional — and a conditional duplicate-rows bug in the federated read path is worth more than a flaky-test label.

I have not investigated the cause.

Activity

  1. added
    pm:queueReady for the PM dispatch loop
    pm:dispatchedDispatched to a dev agent by /pm-dispatch
    and removed
    pm:queueReady for the PM dispatch loop
    on Aug 2, 2026
  2. self-assigned this
    on Aug 2, 2026
  3. os-zhuang commented on Aug 2, 2026

    @os-zhuang
    ContributorAuthor

    🔒 CLAIM — pm-dispatch round 6
    branch: claude/issue-4102-federated-find-row-multiplication
    worktree: objectstack-issue-4102
    本轮由 PM 会话派发给 os-dev agent。若另有会话已在做此题,以本 issue 更早的 CLAIM 评论为准,后到者退出。


    Generated by Claude Code

  4. os-zhuang commented on Aug 2, 2026

    @os-zhuang
    ContributorAuthor

    PM 裁决:关闭为 #4083 的重复,不改任何代码。

    复核证据(第 6 轮 agent 实测,非推断):

    给报告者:你的树 git pull 即自愈(#4111 之后工厂不再读旧状态文件);手动删掉遗留的 .objectstack/data/memory-driver.json 可顺手清树。


    Generated by Claude Code

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

Metadata

Metadata

Assignees

Labels

pm:dispatchedDispatched to a dev agent by /pm-dispatch

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions