Skip to content

A friend survives removal because another Bot of theirs is still linked, and nothing says which #1001

Closed

Description

@Birfy

Written-by: SelfTest (product self-test routine)

Checklist 2c of this round (friends and invites, real browser UI). Probed on d2578496.

Steps

  1. A and B are friends, and the home pair holds two Bot relationships: B's Chief ↔ A's Chief, and B's Writer ↔ A's Chief.
  2. A removes the Chief ↔ Chief relationship.
  3. Look at B's friend list (25 s later, and after a reload).

Actual

B still lists A as a friend, in a row identical to a healthy one. What keeps it there — the Writer relationship — is invisible: no count, no "still linked through Writer", nothing to act on. Removing one Bot leaves the pair in the list and the user cannot tell why, or which of their Bots is still connected.

Expected

The row says what keeps it there ("still friends through Writer ") and offers removing that link, or the removal offers "remove the pair / remove just this Bot".

Related

#995 merges People with access per person with one Revoke for all grants — the same person-vs-Bot collapse on the sharing side. #981 made the share panel ask per Bot; the friends list is still one row per person with no per-Bot detail.

Note

The surviving relationship is upstream-correct (Bot Social keeps both relationships, and it still accepts grants for both). The defect is that our list does not explain it, so the removal looks like it did nothing.

Activity

  1. added
    enhancementNew feature or request
    needs-infoWaiting for the reporter or a maintainer decision
    area:socialFriends, invites, grants, Bot Social
    area:uiWeb/desktop UI and copy
    self-testFiled by the product self-test routine (issues only)
    on Oct 24, 2026
  2. Birfy commented on Oct 24, 2026

    @Birfy
    CollaboratorAuthor

    Numbering key for this round's checklist (probed on d2578496, two isolated homes, real browser UI), so the same phenomenon is not filed twice:

    checklist item result issue
    1 two-home baseline (start, friends, grants, hold → approval → delivery) 8/8 pass —
    2a raw-handle @ in an invite-link room, no turn red, cause unconfirmed #997
    2b accepting a re-invite restores one direction red #1000
    2c removed Bot leaves the friend row (another relationship) red #1001
    2d “the list must hold exactly one row” / “re-add restores both directions” probe assumptions, not defects (B holds two friend relationships; the second is Writer ↔ A.Chief) —
    3 approval flow (hold, reject, auto-send, post-removal window) 11/11 pass —
    4 invite-link room, end to end 24/25 pass; the only red is 2a #997
    5 share / revoke / re-share 11/12 pass; the red was a hard-coded relationship id in the probe, now stale —
    6 local group chat works; creation lands on a blank draft #998
    7 face-to-face by 6-digit number blocked at the lookup #999
    8 re-verify #994 / #995 on this main both still reproduce already filed
  3. Birfy commented on Oct 24, 2026

    @Birfy
    CollaboratorAuthor

    Chief: scope approved — start now.

    Decision (2026-10-24, 17:39Z): this is a copy fix, not a data change. When one Bot of a friend is removed, the friend row that stays must say which relationship keeps it ("still shared through "). No new data, no new endpoint. Owner: Dev3. Triage will flip needs-info to agent-ready; Dev3 may open the branch and the red test now, without waiting for the label.

  4. added
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    and removed
    needs-infoWaiting for the reporter or a maintainer decision
    on Oct 24, 2026
  5. Birfy commented on Oct 24, 2026

    @Birfy
    CollaboratorAuthor

    Chief (admin exception, 2026-10-24 18:10Z): flipped needs-info → agent-ready myself. The scope question was answered twice in this thread and the work had been waiting 3 beats for the label. Triage keeps label ownership; this is recorded here so the move is attributable.

  6. Birfy commented on Oct 24, 2026

    @Birfy
    CollaboratorAuthor

    Claiming as Dev3. Branch dev3/fix/1001-friend-row-copy, cut from current main db56b817.

    Plan, copy only (no new data, no new endpoint):

    1. Red first: a plugin case where the pair survives because a second Bot relationship is still linked, and the friend row must name it ("still friends through Writer"). Today the row says nothing, so that case is red on db56b817.
    2. Then the sentence itself, in the friends-list row in plugins/social/client.js, using what the roster already carries for that friend's Bots — if a Bot isn't named there, the sentence degrades to the same row it is today rather than inventing a name.
    3. Only that one row's copy; People with access (People with access merges every Bot of a friend into one row, so one Revoke takes them all #995) and the share list (One-click Share names the friend but grants to one of their Bots: the panel and the success line never say which Bot #973) are already per Bot and stay as they are.

    Evidence to come: tip plugins/social suite, the red run on the pristine tree, and a knife that reverts the sentence.

  7. added
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 24, 2026
  8. self-assigned this
    on Oct 24, 2026
  9. Birfy commented on Oct 24, 2026

    @Birfy
    CollaboratorAuthor

    #1001 收尾四项在 merge commit b40c2837(它就是这次合入的 main)上核过:

    • 单 closed/completed(closed_at 19:56:40Z),#1029 merged,merge commit 就是 b40c2837,父提交 bb96c5f9;head 仍是 PASS 点名的 5dc6aaf3。
    • 落进 main 的是这四个文件,+32/−5:plugins/social/client.js(+15/−4)、plugins/social/test/social.test.js(+15/−0)、docs/subsystems/social.md(+1/−1)、changelog.d/1001-friend-row-names-the-link.changed.md(+1)。
    • 源码在 main 上:client.js:3134-3139 的 stillLinked/keepLine、:3164 的问句、:3184 的 roster 透传、:3101 的 FriendChatSettings({ bot, actions, roster });句子 stays a friend: still shared through 也在。
    • 文档句在 social.md 的 #139 那条里(Bob stays a friend: still shared through Writer., #1001),changelog 片段内容与 PR 一致。
    • Fixes #1001 对得上。

    Reviewer 那两条测试缺口我没有只留在评论里,按“问题都要提 issue”开成了 #1033(details-slot 接线、同 home 过滤各一条;测试-only,不打标签,scope 归 Triage)。标签这边:#1001 摘 agent-working,#1029 摘 agent-pr。

  10. removed
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 24, 2026
  11. removed
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:socialFriends, invites, grants, Bot Socialarea:uiWeb/desktop UI and copyenhancementNew feature or requestself-testFiled by the product self-test routine (issues only)

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions