fix(channels): await persisted session hydration before enabling plugins#1888
Conversation
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
CI 检查未通过以下 job 在本次自动化 review 时未通过,请修复:
本次自动化 review 暂缓,待 CI 全部通过后将重新处理。 |
Code Review:fix(channels): await persisted session hydration before enabling plugins (#1888)变更概述本 PR 修复了 方案评估结论:✅ 方案合理 将异步初始化结果存储为 问题清单🔵 LOW — 新增代码缺乏测试覆盖文件: 问题说明:Codecov patch 覆盖率为 0%,两条新增行均无测试覆盖。 修复建议:在 it('should expose ready promise that resolves after session hydration', async () => {
const manager = new SessionManager();
await expect(manager.ready).resolves.toBeUndefined();
// verify activeSessions populated from mocked DB
});汇总
结论✅ 批准合并 — 无阻塞性问题 方案正确且最小化,解决了真实的隐式竞态条件。唯一问题为低优先级的测试覆盖缺失,不影响合并。 本报告由本地 |
|
✅ 已自动 review,无阻塞性问题,正在触发自动合并。 |
Closes #1889
Summary
loadActiveSessions()promise as a publicreadyproperty onSessionManagersessionManager.readyinChannelManager.initialize()before creatingPluginManagerand loading pluginsMotivation
SessionManagerfires async hydration (loadActiveSessions()) in its constructor without awaiting it.ChannelManager.initialize()then immediately passes the session manager to plugins. Today this worksby accident — both hydration and plugin loading share the same
getDatabase()promise, so microtaskordering guarantees hydration completes first. But this is implicit and fragile: any future refactor
(caching the DB instance, reordering startup) could silently break it, causing
getSession()to misspersisted sessions and create duplicate conversations.
Diff
+5 −1across 2 files (no logic changes, explicit await added)Files changed
src/process/channels/core/SessionManager.ts— store hydration promise asreadypropertysrc/process/channels/core/ChannelManager.ts—await this.sessionManager.readybefore plugin setupTesting
bunx tsc --noEmit— no type errorsbun run test— 206 files passed, 2023 tests passedRisks / Side effects