Repository navigation
Friend chat: a message sent in the first seconds after an invite join is refused and lost #442
Description
What happened
2026-10-19 18:03 (Asia/Shanghai), the owner's Mac test instances (3080 = danyang.home, 3081 = friend.home), Bot Social prod.
- friend.home joined an invite for the Bot 测试 on danyang.home.
- About 8 seconds later, the owner typed "Hi" in the new friend chat on 3081 (18:03:12).
- Bot Social delivered it, but 3080 dropped it: it had not yet recorded 测试's local grant for the new friend, so the inbound message was refused and lost. No reply, and no error was shown to the sender.
- The owner sent "Hi" again, which tripped Bot Social loop detection and paused the chat (fixed separately in Bot Social docs: Magpie-style LESSONS, code-standards, and review skill #28/ci: CI modeled on yetone/magpie (macOS leg, plugin tests + coverage, package check, tag release) #29 and FlyBot Friend chat stuck 'paused' after Extend: remove the turn limit and the Extend UI (owner decision 2026-10-19) #439/Remove Extend from paused friend chats; a paused chat says to send again (Fixes #439) #440).
Expected
A message that arrives right after an invite join is never silently lost. Either:
- the receiving FlyBot records the grant before (or as part of) acknowledging the join, or
- an inbound message for a not-yet-known grant is held and retried once the grant syncs (short window), instead of being refused and dropped,
- and if it is still refused, the sender sees a clear "Not sent" line rather than silence.
Notes
- Found while fixing the paused-chat bug; prod audit log shows delivery at 18:03:12 and no reply.
- Probably touches the social plugin's inbound/grant-sync path; tier to be set by the controller.
Activity
Birfy commentedon Oct 19, 2026
Triage (maintenance run, 2026-10-19 18:55 Asia/Shanghai)
Where it fails today: an inbound friend message goes through the owner policy in
core/src/host/hooks.js(rt.deliverwrapper). When the receiving home has not yet synced the new talk-through grant from the invite join, the policy saysdeny, the delivery is only logged (delivery to … refused) and dropped. Nothing goes back to the sender. The grant sync (syncOutgoingGrantsinplugins/social/src/social.js) runs on the roster fetch, so a message that lands in the first seconds after a join can beat it.Proposed fix (scope: social plugin inbound path + the owner-policy deny branch, no Bot Social change):
Options for the owner: (a) the above, sync-and-retry plus a Not sent notice (recommended); (b) also make the join itself wait for the grant record before acknowledging (needs a Bot Social change, bigger); (c) only the Not sent notice, no retry.
Waiting for the owner's confirmation before
agent-ready.Birfy commentedon Oct 19, 2026
Owner decision (2026-10-19 18:58 Asia/Shanghai): option b. Make the invite join write the grant before the join is confirmed, so the receiving FlyBot already knows the new friend's grant when the first message arrives (no refuse-and-drop window). This needs a Bot Social server change (file a linked Birfy/bot-social issue; prod deploy only after the owner's yes) plus the matching FlyBot change. If a message is still refused for a missing grant, the sender must see a clear "Not sent" line, never silence.
Birfy commentedon Oct 19, 2026
Claimed for development (2026-10-19 20:00 Asia/Shanghai). Branch
fix/442-invite-grant-before-joinoff main753b7e9. Working in parallel this maintenance run.Birfy commentedon Oct 19, 2026
Linked Bot Social server work: Birfy/bot-social#30 (grant before join confirm). Prod deploy of that change still needs the owner's explicit yes.
Birfy commentedon Oct 19, 2026
Re-claimed (2026-10-19 20:57 Asia/Shanghai): the 20:00 run's worker stopped without changes; development restarts now on the same branch name off main
753b7e9.Keep a message sent right after an invite join from being lost (#449)
Birfy commentedon Oct 19, 2026
Maintenance cleanup (2026-10-19 21:57 Asia/Shanghai): #449 merged to main (
58f7a52); removing staleagent-workingand assignee from this closed issue.