root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(dashboard): use per-project chatStore in chat session API routes

Browse Source 
In multi-project mode, all /chat/sessions* handlers used options.chatStore
(the home-dir project's store) regardless of the projectId query param.
Sessions in secondary projects were invisible via the API.

Root cause: registerChatRoutes accessed options.chatStore directly instead
of routing through resolveProjectChatContext (already used correctly in
registerChatRoomRoutes for the rooms API).

Fix: introduce resolveScopedChatStore(projectId) helper that delegates to
resolveProjectChatContext, replacing all ten options.chatStore usages.
Falls back to default store when engineManager is absent (backward compat).

Tests: add two cases to verify engine-scoped chatStore is used when
engineManager is configured for the requested projectId.
This commit is contained in:
Josemi Liebana
2026-05-22 12:11:14 +02:00
parent fbf7e2cb4d
commit 7f01b5341c
3 changed files with 114 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
.changeset/fix-chat-sessions-multi-project-scope.md Normal file
View File

@@ -0,0 +1,21 @@
---
"@runfusion/fusion": patch
---
Fix chat session API endpoints ignoring `projectId` in multi-project mode.
`GET /chat/sessions`, `GET /chat/sessions/:id`, `GET /chat/sessions/:id/messages`
and related mutation endpoints all used `options.chatStore` (the home-directory
project's store) regardless of the `projectId` query parameter. In a multi-project
daemon (e.g. running from `~/`) sessions belonging to secondary projects were
invisible — list returned empty, fetching by ID returned 404.
Root cause: `registerChatRoutes` accessed `options.chatStore` directly instead of
routing through the per-project `resolveProjectChatContext` helper (already used
correctly by `registerChatRoomRoutes` for the rooms API).
Fix: introduce a `resolveScopedChatStore(projectId)` helper inside
`registerChatRoutes` that delegates to `resolveProjectChatContext`, and replace
all ten `options.chatStore` usages with calls to this helper. When `engineManager`
is present and has an engine for the given `projectId`, the engine's own
`ChatStore` is used; otherwise falls back to the default store (backward compatible).