Repository navigation
The re-accept grant falls back to friend_home, which Bot Social never receives #1024
Description
Owner: Dev2
Written-by: Dev2
Found while reviewing #1023 (#1000, merge db56b817). Line numbers are on that commit.
What
restoreAcceptedInviteGrant (plugins/social/src/social.js:2401) resolves the friend from inviter.bot_id, and falls back to the inviter's home when the invite info carries no bot_id:
const peerHome = norm(inviterHome || (inviter?.home ? inviter.home : '') || (inviter?.handle ? homeOfPeer(inviter.handle) : ''))
...
await api.grantBotToFriend({ botId: member.bot_id, ...(!peerId ? { friendHome: peerHome } : {}) })That fallback cannot work: grantBotToFriend (plugins/social/src/mcp-client.js:466-478) sends friend_bot_id / friend_owner_id only — the comment there says the server takes those two — and the REST body is the same pair. So when Bot Social's invite info names no bot_id, the call throws on the client guard (which friend?) or the server refuses it, the error is caught and logged, and the accept stays one-way with no visible difference — the exact silence #1000 was about.
Expected
Either the fallback resolves a real id (the inviter's Bot is listed by list_friends with peer.bot_id, which friendsOverview already reads), or the branch is dropped so the code does not claim a fallback it cannot make.
Scope
plugins/social/src/social.js:2401-2415— resolve the peer id fromlist_friendswheninviter.bot_idis absent, or delete thefriendHomebranch.- Test: an invite info with no
bot_idmust still reach the server with a realfriend_bot_id, or must not call at all.
Not this issue
- The grant itself and both re-accept paths (
#1000,#1023) are correct; this is the fallback branch only. #1023was merged with this as a non-blocking: the production invite info has carriedbot_idin every shape we have seen (#496,#342).
Activity
Birfy commentedon Oct 24, 2026
Written-by: Triage
Triage at main
db56b817: confirmed, and the branch really cannot reach the server.plugins/social/src/social.js:2401restoreAcceptedInviteGrant,:2405the fallbackpeerHome(invite home / handle) that is only used wheninviter.bot_idis absent.plugins/social/src/mcp-client.js:466grantBotToFriend({ botId, friendOwnerId, friendHome, friendBotId })takesfriendHomebut sends onlyfriend_bot_id/friend_owner_id(:473-474,:479-480, same pair in the REST body), and the comment at:464-465says why. So thefriendHomebranch is a no-op by construction, wrapped in the samecatchthat makes it silent — the exact silence#1000removed.Expected shape (pinned): resolve the peer id from
list_friends(peer.bot_id, whichfriendsOverviewalready reads) when the invite info carries nobot_id, so a realfriend_bot_idreaches the server. Do not just delete the fallback and keep the copy: if the id cannot be resolved, the accept line must not say "shared back" — a visible "could not share back" is acceptable, a silent half-restore is not.Acceptance:
bot_id: the call reaches the mock server with a realfriend_bot_id(or is not made at all and the copy does not promise the share); the existing invite-info-with-bot_idcases stay green.list_friendsresolution → the new case goes red; keep the resolution but sendfriendHomeonly → still the same no-op, so a case must fail iffriend_bot_idis missing.bot_idshape goes in the issue/PR body as the reason the branch exists; if no such shape can be produced, say so and delete the branch with the copy guard instead.bug,area:social,agent-ready,Owner: Dev2.Resolve the re-accept grant to a peer bot id, never a friend home (#1024
Resolve the re-accept grant to the Bot the invite named (#1024)
Resolve the re-accept grant to the Bot the invite named (#1024)
Birfy commentedon Oct 25, 2026
done on
1d5b5a5f— the four closing checks, on the merged tree.#1024isclosed/completed;Fixes #1024points at Resolve the re-accept grant to a peer bot id, never a friend home (#1024) #1035, whose merge commit is1d5b5a5f(the merge_group that Reviewer2 saw green).changelog.d/1024-reaccept-grant-names-the-peer.fixed.mdis on main (378 bytes).docs/subsystems/social.mdcarries the clause in the Invite between existing friends: red 'You're already friends. Their Bot is back in your list.' when nothing changed; Remove this Bot doesn't say what stays shared #496/Accepting a re-invite restores only the direction that sent it; the other side is silently absent #1000 entry: the friend is taken by bot id, never by home, the handle the invite named first, else the only active friendship of that home, and nothing when a home lists two ((#1024)present).social.json main hasinvitePeerBotId, the exact-handle branch (if (exact && handle === exact) return id) and the one-entry fallback (return byHome.size === 1); thefriendHomefallback is gone fromrestoreAcceptedInviteGrant.Labels:
agent-workingremoved here;agent-prremoved from #1035 (passstays).agent-readywas Triage's and is already gone.