Repository navigation
feat(social): friends' Bots and rooms in the main sidebar list, no separate section - #145
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ec132c881e
ℹ️ 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".
| void Promise.all((actions.roster?.rooms ?? roster?.rooms ?? []).flatMap(room => { | ||
| const hit = (room.participants ?? []).find(p => p.remote && p.handle === handle && p.leftSeq === undefined) | ||
| return hit ? [actions.updateRoom(room.id, { removeParticipants: [{ kind: 'bot', id: hit.handle || hit.id, remote: true }] })] : [] | ||
| })).catch(e => setError(errorText(e))) |
There was a problem hiding this comment.
Do not remove a hidden Bot from rooms twice
When the friend’s Bot is a live participant in any room, social/hide-remote already invokes afterHideRemote/leaveRoomsWith before it returns (plugins/social/src/social.js), so this loop sends a second removal against the stale browser roster. The host-started removal wins the room lock and the duplicate update-room then rejects with “That participant is not in the room”; the catch consequently shows an error after a successful Remove. Rely on the endpoint’s background leave (or exclude the leftRooms it reports) instead of issuing the same mutations again.
Useful? React with 👍 / 👎.
| ...roster.rooms.map(room => ({ kind: 'room', item: room, at: stamps[room.id] ?? room.createdAt })), | ||
| // Own Bots, friends' Bots, groups and face rooms share one list. A remote chat | ||
| // still uses BotRow's globe; gone / hidden / home-level remotes stay out. | ||
| ...roster.bots.filter(bot => bot.id !== roster.mainBotId && isListedRemoteChat(bot)).map(bot => ({ kind: 'bot', item: bot, at: stamps[currentPart(bot)] ?? bot.createdAt })), |
There was a problem hiding this comment.
Keep remote Bots out of the local Bot tree
When @flybot/tree is enabled, including remote chats as kind: 'bot' makes the code below pass them to botTree, and the complete tree is rendered ahead of every room and Agent entry. A friend’s Bot therefore appears under Main (and disappears when Main is collapsed) before the user’s own group chats, bypassing the new own-before-foreign comparator and the advertised unified ordering. Keep only local Bots in the tree and render remote chat entries in the flat ordered tail.
Useful? React with 👍 / 👎.
ec132c8 to
9459777
Compare
The separate Friends' Bots section duplicated the team list. Own and friends' chats now share one list (globe / people marks), Past rooms stay folded, Copy my handle lives on +, and Auto-send / Remove live on that friend's Bot settings. Co-authored-by: Danyang Chen <birfychen@gmail.com>
Friends' Bots is no longer a sidebar section, so the sent receipt must not name it. A @ of a friend who is not in the room still 1:1-sends (ThinkFlowLab#80/ThinkFlowLab#81); ThinkFlowLab#144 only skips when they are already a participant. The hold receipt waits for the followup instead of 30 ms, because persist races remote-chat open after publish. Co-authored-by: Danyang Chen <birfychen@gmail.com>
9459777 to
f905c98
Compare
Resolve docs/subsystems/social.md (keep main's compact card / Always approve and unique face-room titles with this PR's unified list) and regenerate patches/ds-bot from core/.
Codex review on ThinkFlowLab#145: - With @flybot/tree on, remote chats were passed to botTree and drawn under Main, ahead of rooms and hidden when Main collapsed. Only own Bots are tree nodes now; a friend's Bot stays in the ordered flat list. - Remove this Bot issued updateRoom removals after social/hide-remote, which already leaves every room holding that Bot. The duplicate lost the room lock and showed "not in the room" after a good Remove. The client now relies on the endpoint.
Owner request (usability and simplicity): no separate "Friends' Bots" section.
Friends' Bots and live face rooms now sit in the same sidebar list as your own, with one small marker (globe / people), own first, then by recency. Ended face rooms stay under Past rooms. "Copy my handle" moved to the
+menu. Per-friend Auto-send and "Remove this Bot" live in that friend's Bot settings; face-room Auto-send stays on the open room. The separate header, per-friend groups and duplicate checkboxes are gone.Verified:
ARCH_DOCS_BASE=upstream/main npm run verifypasses.