Repository navigation
Fix the joiner never seeing the inviter's Bot after Add friend (Fixes #342) - #344
Conversation
…shared with us (#342) Bot Social's real join_invite answers with `inviter` = the invited Bot itself and no `bot` field. #334 made the grant sync run before the first publish, so with nothing marked inbound the server's talk-through grant on the joiner's Bot was stored as the joiner sharing back, which hid the inviter's Bot and listed the inviter under People with access. A member-level `inviter` now counts as the offered Bot: it is marked inbound before the refresh, as with the older `bot` shapes. #303 (no dead chat for the Bot that joined our invite) and the #334 review fixes are unchanged. Fixes #342
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0869a703de
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const inviterBot = home && joined.inviter?.handle && homeOfPeer(joined.inviter.handle) !== norm(joined.inviter.handle) ? joined.inviter : undefined | ||
| const offered = joined.bot ?? joined.inviter?.bot ?? joined.offered_bot ?? inviterBot |
There was a problem hiding this comment.
When the real response has status: 'pending_target', this fallback still treats inviter as offered, after which rememberInbound permanently records its handle; inboundBots is never cleared if the request is rejected or expires. If that same remote Bot later joins one of this user's invites through another local Bot, keepGrantedRemote treats the stale marker as proof that the Bot was shared inbound, so the reverse-only Bot appears in Friends' Bots and isTalkThroughGrant can also hide the genuine outgoing grant from People with access. Track pending invitations separately or only promote this marker once that relationship becomes active.
Useful? React with 👍 / 👎.
|
Maintenance review at tip 0869a70 (posted from the author's account, so it is not an independent PASS and records none). Risk tier T3 ( The fix reads Bot Social's real Needs an independent PASS at this tip and the maintainer's one-click approval (T3). |
Fixes #342
What changed
Before: after B accepted A's per-Bot invite, B never saw A's Bot, and B's own Chief listed A under People with access. Bot Social's real
join_inviteanswers withinviter= the invited Bot itself (a member handle) and nobotfield, so the joiner did not mark the shared Bot inbound. #334's awaited grant sync then stored the server's talk-through grant on B's Chief as B sharing back, and the re-filter hid A's Chief.After: a member-level
invitercounts as the offered Bot (the olderbot/inviter.bot/offered_botshapes still win). It is marked inbound before the refresh, so the talk-through grant is read as talk-through: A's Chief shows at once, the toast names it, and B's Bots stay default-deny. #303 (no dead chat for the Bot that joined our invite) and the #334 review fixes (rosterFetched, fail closed on sync failure, classify against the fresh roster) are untouched. Existing installs already hit by this are not healed here.Tests use the real
join_inviteshape: the #342 repro, #342 + #303 together (empty and non-empty roster, a joiner of our own invite stays hidden), a join pending the inviter's approval, B's Chief and WriterPeople with accessempty after a plain join, and the inviter side staying default-deny. Without the fix 5 of the 6 fail.Verification at the tip
Tip SHA: 0869a70
Ran:
ARCH_DOCS_BASE=origin/main TZ=UTC npm run verify(Node 24): exit 0; core 869, social 236, tree 56, timeline 80, CI scripts 86, interop 37, live-e2e 16 tests pass; arch-docs OK; changelog check OK. CI at the tip: tests-ok and all checks green.Not run (and why): smoke test and a real two-instance self-test (no server change; the repro uses the server's real answer shape); pack/typecheck/actionlint of CI
package(run by CI).