[BUG] 0.1.2-rc.1 历史加载失败：this.ctx.sessionQuery.observeSession is not a function（gateway/internal）

[ashuai]

最新latest: '0.1.2-rc.1'对历史会话有兼容问题，
一直报：历史加载失败：this.ctx.sessionQuery.observeSession is not a function（gateway/internal）
会话列表也有错乱，导致无法使用

[argszero]

This one looks like a different flavor of the same compatibility family, and I want to be precise rather than guess the wrong root cause.

ctx.sessionQuery.observeSession is definitely part of the current core API. In packages/session-query/session-query/src/index.ts:139-144, observeSession is a concrete method on the SessionQueryEngine service, and the harness's own history loader calls it (packages/api/session-controller/src/history.ts:199). So a built, current 0.1.2-rc.1 should expose it on ctx.sessionQuery.

That makes observeSession is not a function a runtime-service mismatch, not an export removal. Possible causes, in order of likelihood for the "latest 0.1.2-rc.1" + "历史加载失败 (gateway/internal)" shape:

1. Stale/mixed install — the process resolved a sessionQuery service from a different generation than the one exposing observeSession. This happens with a partially-updated node_modules (some packages on 0.1.1-rc.2, some on 0.1.2-rc.1) — the session-query service you get is an older shape. A clean reinstall (delete node_modules + lockfile re-resolve) usually fixes it. If you launched via npx, the cache can also pin the old package set; a npx cache clean (or run with the pinned version) helps.

2. A plugin/shadow resolver overriding ctx.sessionQuery — if any installed plugin registers its own sessionQuery service with an older interface, or a Remote-style proxy that doesn't forward observeSession, the composed service won't have the method. Check whether the session-controller is running the real session-query-sqlite provider (that's the concrete owner) vs a remote/proxy one.

3. Version skew between session-controller and session-query — session-controller is the caller that hits observeSession. If session-controller is on a build that expects observeSession but the session-query package it's composed against predates it, you get exactly this. This is the package-peer-skew pattern seen elsewhere (e.g. the stale dsh-* peer tupling).

To pin it down, three quick data points would be ideal:

• Is the failure on a clean install or a web upgrade over an existing node_modules? (If upgrade-over-existing, start with the clean reinstall + npx cache clean.)
• The full stack trace for observeSession is not a function — the frame showing which module constructed the offending sessionQuery tells us whether it's the SQLite provider or a proxy/remote.
• The exact session-controller + session-query* versions npm ls reports in that install.

If you confirm it's #1/#3 (mixed install or peer skew), that's a different class than the export-removal drift — it's a packaging/version-pinning issue, not an API break. Happy to dig into whichever it turns out to be.

(My context: this is in the same contract-drift family as the settingsNamespace/installSettingsSection removal reported in #5599 — but that one is a clean export removal at a pinned commit; #5596 here has the method present in the current API, so I don't want to claim the same root cause without the above confirmation.)