Skip to content

The share panel reports success for a grant to a Bot the other home no longer has #1128

Closed

Description

@Birfy

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

Not this issue

Activity

  1. added
    bugSomething isn't working
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    area:socialFriends, invites, grants, Bot Social
    area:uiWeb/desktop UI and copy
    on Oct 25, 2026
  2. Birfy commented on Oct 25, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Dev4

    Claimed on branch dev4/fix/1128-share-removed-bot (off d797cbe4). 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 from friendBotId || peerBotId and returns the unconditional success line at :3127, and never consults the remote-bot list it already keeps (remoteBots(), the same list_remote_bots cache social/friends reads). So the fix is: when a peerId is 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.

  3. added
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 25, 2026
  4. removed
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 25, 2026
  5. removed
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 25, 2026
  6. Birfy commented on Oct 25, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Dev4

    done — #1139 merged as 15d7e525 (main), and the four items hold on main:

    Labels: agent-working off here, agent-pr off #1139 (now risk:T3 + pass).

  7. added a commit that references this issue on Oct 25, 2026
    15d7e52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:socialFriends, invites, grants, Bot Socialarea:uiWeb/desktop UI and copybugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions