Repository navigation
Description
Owner: Dev4
The client half of #1125, split off so the protocol half does not block it.
What is wrong today
B removes a Bot from its home. A's relationship with that Bot stays active on Bot Social, so A's "Share with a friend" still lists it, e.g. Coder (SelfTest B2). A clicks Share and the panel reports Shared Chief with selftestb2. — a success line — while the grant names a Bot that no longer exists on that home. Nothing can ever arrive, and the row disappears once the fresh grant hides it, so the owner has no way to tell that it failed.
The target behaviour is route (a) in #1125 (revoke on removal), but that is a server-side decision that travels only with the Bot Social version implementing it. Until then this panel lies on any host talking to an older server, so the honest answer belongs here.
What to do
When the share target is a Bot the other home no longer has, do not print a success line: keep the row visible but not shareable, with the reason ("this Bot was removed from that home"), and post no grant.
Detection has to be evidence-based, not a guess: the same lookups this panel already makes (list_remote_bots / the relationship's Bot list) must be what decides the row is stale — do not infer it from a failed delivery after the fact.
Acceptance
- two tests: (1) a share to a live Bot still reports success and posts the grant (unchanged behaviour, One-click Share names the friend but grants to one of their Bots: the panel and the success line never say which Bot #973/The re-accept grant falls back to
friend_home, which Bot Social never receives #1024 cases stay green); (2) a share to a Bot the other home no longer lists reports no success line and posts no grant. - a knife for each: restore the old unconditional success line → (2) red; drop the none-detection → (2) red again.
- no behaviour change when both sides are current: this must not make ordinary shares slower or need an extra round trip beyond the lookups the panel already does.
Not this issue
- revoking grants on member removal (Sharing to a home member that was deleted reports success and can never deliver #1125, needs the Bot Social side);
- the
{"homes":[]}reading, already explained in Sharing the same Bot again after a revoke never reaches the friend: the owner sees the grant, the friend's roster stays empty #970.
Activity
Birfy commentedon Oct 25, 2026
Written-by: Dev4
Claimed on branch
dev4/fix/1128-share-removed-bot(offd797cbe4). Starting after #1112 (PR #1133) and #1076 (PR #1134) are pushed — both are waiting on the Reviewer.Reading the code before deciding the shape, and writing it here so the next round does not repeat it:
social/share-with-friend(plugins/social/src/social.js:3065) resolves the grant target fromfriendBotId || peerBotIdand returns the unconditional success line at:3127, and never consults the remote-bot list it already keeps (remoteBots(), the samelist_remote_botscachesocial/friendsreads). So the fix is: when apeerIdis given and the cached list has an entry for that home and that id is not in it, refuse with the removed-from-that-home reason and post no grant; when the home is not in the cache at all, do not guess — share as before, because a cache miss is not evidence.Stop reporting a share to a Bot the other home removed
Stop reporting a share to a Bot the other home removed
Stop reporting a share to a Bot the other home removed
Birfy commentedon Oct 25, 2026
Written-by: Dev4
done — #1139 merged as
15d7e525(main), and the four items hold on main:closed/completed;Fixes #1128is its own line in the Stop reporting a share to a Bot the other home removed #1139 body;changelog.d/1128-share-removed-bot.fixed.mdis on main;docs/subsystems/social.md:160-162carries the section ("A share to a Bot the other home removed (The share panel reports success for a grant to a Bot the other home no longer has #1128)");removedOnRosterinplugins/social/src/social.js, refusalbot/removed-bot.Labels:
agent-workingoff here,agent-proff #1139 (nowrisk:T3+pass).Stop reporting a share to a Bot the other home removed (ThinkFlowLab#…