🐛 fix(send-message): forward topic-list filter to server response#14160
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8d7c53e1de
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## canary #14160 +/- ##
===========================================
- Coverage 82.60% 68.09% -14.52%
===========================================
Files 475 2267 +1792
Lines 35367 194401 +159034
Branches 6239 20349 +14110
===========================================
+ Hits 29216 132380 +103164
- Misses 6021 61891 +55870
Partials 130 130
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
9be148c to
1bafc1d
Compare
1bafc1d to
7ddad02
Compare
Without this, sending a message refreshes `topicDataMap` with an unfiltered list, so completed/cron topics flash back into the sidebar until the next SWR revalidation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
internal_updateTopics rewrote topicDataMap[key] from scratch and dropped excludeStatuses / excludeTriggers, so #getTopicFilter returned undefined on the second sendMessageInServer call and stopped forwarding the filter to the server — completed/cron topics could leak in until SWR revalidated. Carry the filter fields forward from currentData, matching loadMoreTopics. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
7ddad02 to
cecc318
Compare
…behub#14160) * 🐛 fix(send-message): forward topic-list filter to server response Without this, sending a message refreshes `topicDataMap` with an unfiltered list, so completed/cron topics flash back into the sidebar until the next SWR revalidation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * 🐛 fix(topic): preserve filter fields in internal_updateTopics internal_updateTopics rewrote topicDataMap[key] from scratch and dropped excludeStatuses / excludeTriggers, so #getTopicFilter returned undefined on the second sendMessageInServer call and stopped forwarding the filter to the server — completed/cron topics could leak in until SWR revalidated. Carry the filter fields forward from currentData, matching loadMoreTopics. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…behub#14160) * 🐛 fix(send-message): forward topic-list filter to server response Without this, sending a message refreshes `topicDataMap` with an unfiltered list, so completed/cron topics flash back into the sidebar until the next SWR revalidation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * 🐛 fix(topic): preserve filter fields in internal_updateTopics internal_updateTopics rewrote topicDataMap[key] from scratch and dropped excludeStatuses / excludeTriggers, so #getTopicFilter returned undefined on the second sendMessageInServer call and stopped forwarding the filter to the server — completed/cron topics could leak in until SWR revalidated. Carry the filter fields forward from currentData, matching loadMoreTopics. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
💻 Change Type
🔗 Related Issue
N/A
🔀 Description of Change
sendMessageInServerreturns the latest topic list alongside the new messages so the sidebar reflects the just-created topic. The frontend was calling it without the filter the active sidebar uses (excludeStatuses: ['completed'],excludeTriggers: ['cron','eval']), so the server replied with the unfiltered list andinternal_updateTopicsthen wrote that list back overtopicDataMap[containerKey].items— completed/cron topics flashed back into the sidebar until the next SWR revalidation.This PR threads the filter end-to-end:
packages/types/src/aiChat.ts—SendMessageServerParamsandAiSendMessageServerSchemaget an optionaltopicFilter: { excludeStatuses?, excludeTriggers?, includeTriggers? }.src/server/routers/lambda/aiChat.ts— forwardsinput.topicFiltertogetMessagesAndTopics.src/server/services/aiChat/index.ts— acceptstopicFilterand spreads it intotopicModel.query; ensures it does not leak intomessageModel.query.src/store/chat/slices/aiChat/actions/conversationLifecycle.ts— adds private#getTopicFilter(agentId, groupId)that reads the filter from the activetopicDataMapentry and passes it at bothsendMessageInServercall sites (Gateway/Client main path and the heterogeneous-agent path).🧪 How to Test
Repro before fix:
completedtopics), send a new message.After fix: the list returned by
sendMessageInServeralready respects the active filter, so completed topics never reappear.Targeted tests added in
src/server/services/aiChat/index.test.tsto cover:topicFilterforwarded intotopicModel.query.topicFilterdoes not leak intomessageModel.query.📸 Screenshots / Videos
N/A — sidebar regression, no new UI surface.
📝 Additional Information
Both call sites of
sendMessageInServerare updated; theisolatedTopicskip path atconversationLifecycle.ts:640is unchanged because that one already avoids writing to the main sidebar'stopicDataMap.🤖 Generated with Claude Code