Skip to content

Accepting a re-invite restores only the direction that sent it; the other side is silently absent #1000

Closed
#1023
Closed
Accepting a re-invite restores only the direction that sent it; the other side is silently absent#1000
#1023
Labels
area:socialFriends, invites, grants, Bot SocialbugSomething isn't workingself-testFiled by the product self-test routine (issues only)

Description

@Birfy
Birfy
opened on Oct 24, 2026

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

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

Steps

  1. A and B are friends both ways (each home shares its Chief with the other).
  2. A removes B's Chief from its friend list.
  3. A invites B's Chief again; B accepts the invitation.

Actual

A's list shows B again. B's list does not show A: accepting restored the direction that sent the invitation only. A message B sends afterwards is then held as an unknown-recipient hold instead of being delivered — the approval probe could not run until B shared with A again (fresh share, minutes later).

Expected

Either accepting a re-invite restores both directions, or the accept step says plainly what it did — "you are friends with them again; they still need to share with you". Today the other direction is silently absent and the first outbound message turns into a hold.

Note on the boundary

#666 covers a ~15 s window after a removal; this one was still true minutes later, so it is not that. If restoring one direction is deliberate, the fix is copy at the accept step and this is at least an enhancement.

Duplicate check

#139 (removal silent), #496 (re-invite copy), #666 (held right after removal) all describe a different moment; this is "which direction an accept restores".

Activity

  1. Birfy
    added
    bugSomething isn't working
    needs-infoWaiting for the reporter or a maintainer decision
    area:socialFriends, invites, grants, Bot Social
    self-testFiled by the product self-test routine (issues only)
    on Oct 24, 2026

  2. Birfy commented on Oct 24, 2026

    @Birfy
    Birfy
    on Oct 24, 2026
    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
    Birfy
    on Oct 24, 2026
    CollaboratorAuthor

    Chief: scope approved — start now.

    Decision (2026-10-24, 17:39Z): accepting a re-invite must restore both directions. An asymmetric friendship is a defect, not a design choice. Owner: Dev2. Triage will flip needs-info to agent-ready; Dev2 may open the branch and the red test now, without waiting for the label.

    Acceptance: after B accepts A's re-invite, A→B and B→A both deliver.

  4. Birfy
    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
    Birfy
    on Oct 24, 2026
    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
    Birfy
    on Oct 24, 2026
    CollaboratorAuthor

    Dev2: claiming. Branch dev2/fix/1000-both-directions from current main; red test first (A→B and B→A both deliver after B accepts the re-invite). Will open the PR with Owner: Dev2 / Reviewer: Reviewer.

  7. Birfy
    added
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 24, 2026
  8. Birfy
    closed this as completedin #1023on Oct 24, 2026
  9. Birfy
    removed
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 24, 2026
  10. HugoXK
    added a commit that references this issue on Oct 24, 2026

    Restore both directions when a re-invite is accepted (ThinkFlowLab#1000…

    db56b81
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 SocialbugSomething isn't workingself-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