fix(channels): keep direct chat replies in Multica#5645
Merged
Bohan-J merged 1 commit intoJul 20, 2026
Conversation
|
@beastpu is attempting to deploy a commit to the IndexLabs Team on Vercel. A member of the Team first needs to authorize it. |
beastpu
marked this pull request as ready for review
July 20, 2026 01:58
A chat session can retain its Lark or Slack binding after a user continues the same session from the Multica UI. The outbound subscribers treated that binding as sufficient proof that every later task originated from the external channel, so a web/mobile direct-chat reply (or failure) leaked back into the bound external chat. Direct-chat tasks are distinguishable by a non-NULL chat_input_task_id (channel-created tasks leave it NULL). The subscribers now look up the channel binding first and, only for bound sessions, load the task to classify its origin before loading credentials or sending — so web-only completions early-return on the cheap binding lookup instead of paying a GetAgentTask query on every chat completion. Origin classification fails closed: the in-process bus has no retry, so a transient lookup failure drops the reply rather than risking a private turn reaching the channel. Slack extracts the task id from the typed chat-done payload emitted by TaskService. Adds regression coverage for both integrations: a bound session plus a direct task sends nothing; a bound session plus a channel task still sends exactly one reply. Closes multica-ai#5644
beastpu
force-pushed
the
codex/fix-lark-web-chat-outbound
branch
from
July 20, 2026 02:19
bc0ee2a to
ea8cbf3
Compare
Collaborator
|
Thanks for the fix, @beastpu! 🙏 We reviewed this end-to-end and verified the core invariant: classifying task origin by Merging now — appreciate the contribution! 🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #5644
Summary
Root cause
A chat session can retain its Lark or Slack binding after a user continues the same session from the Multica UI. The outbound subscribers treated that binding as sufficient proof that every later task originated from the external channel. Direct-chat tasks are distinguishable by a non-NULL chat_input_task_id, so the subscribers now enforce that boundary before loading installation credentials or sending.
Slack also extracts the task id from the typed chat-done payload emitted by TaskService and fails closed when task origin cannot be established.
Tests
A local run of go test ./cmd/server reaches the existing readiness integration test but fails because /readyz and /healthz return 503 without healthy local dependencies; the focused channel, handler, and service packages pass.