mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-21 01:00:54 +02:00
17bb0bbebc
Review fix (Niko, PR #3899). v1 resolved the chat task initiator from chat_session.creator_id at claim time. That is correct for web chat and Lark p2p (creator == sender), but WRONG for Lark group chats: the group session creator is deliberately the installer (stable identity across member churn), not the message sender. So in a Lark group, every member who triggered the agent showed up in the brief as the installer/owner — the exact bug this issue is about, still live at that entry point. Capture the real sender at enqueue time instead of deriving it from the session creator at claim time: - migration 117: agent_task_queue.initiator_user_id (FK user, ON DELETE SET NULL); NULL for non-chat and pre-migration rows. - EnqueueChatTask now takes an explicit initiatorUserID. Web chat passes the authenticated request user; the Lark dispatcher threads the inbound sender (binding.MulticaUserID) through scheduleRun -> flushChatRun. The debouncer keeps the latest scheduled flush per session, so in a multi- sender silence window the LATEST sender wins (documented + tested). - claim handler resolves the initiator from task.initiator_user_id and drops the creator_id fallback entirely. The Lark group session creator stays the installer (unchanged) — only the task initiator is corrected, keeping the two concepts cleanly separate. Tests: dispatcher group regression (initiator = sender, not installer), latest-sender-wins, p2p initiator assertion; the chat claim handler test now sets creator != initiator and asserts the stored sender wins. Co-authored-by: multica-agent <github@multica.ai>