You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Co-seat shared-group Bot outbound still waits for owner Approve #1175
E2E 2026-10-25 Asia/Shanghai on box FlyBot :3090/:3091 vs prod Social: ordinary shared group with Friend's Bot on the other home.
Human lines from B's Bot path showed Waiting for approval until B clicked Approve; A's outbound to B's Bot also needed Approve. Owner expectation from earlier: once Bots share a live group/room, they should message without separate friendship/Sharing friction (「拉了群就应该都能发消息」).
Related prior work: #1145 co-member messaging; #1122/#1117 Auto-send clears. This may be a remaining blanket outbound / pair Auto-send gap for Friend's Bot seats.
Claim
Claimed by Birfy / bot-im — will implement after #1174 merges unless overlapping.
Re-triaged on main 97065bac: needs-info, because the report describes two very different situations with the same words, and the code distinguishes them:
Auto-send is off for that room — then a held line is by design. social.js:176-183 names face_room_auto_send_off as a real per-room switch, :4497 only auto-sends a face line when autoSendFaceLine succeeds, and :4510-4515 refuses unless held.autoSendHold === true. A pair that has never set it reads “Waiting for approval” forever, and the owner's Approve is the feature working.
A blanket hold that should have been cleared — autoSendRoomEnvelope clears the blanket mvp.all_outbound_requires_approval hold for a room line (:1825, :1867, :2000), and :181-182 says explicitly that neither outbound path clears face_room_auto_send_off. If the pair is a co-seat in one open room and the room's own Auto-send is on, a card here is a bug — in the clearing path, not in the seat.
What I need on this issue to decide between them, all of it from the same attempt:
the hold's holdReason and reasons (the face_room_auto_send_off switch versus a blanket reason);
whether the room's own Auto-send switch reads on for the holding Bot, and for the other seat;
whether the same pair, outside any room, also waits — if yes this is the 1:1 path (#948 territory), not the room path.
With those four answered this becomes either “working as designed, set the room's Auto-send” (and closes) or an agent-ready bug with a named file. Labels: area:social added, because this is Bot Social outbound, not a UI defect.
Activity
Birfy commentedon Oct 25, 2026
Written-by: Triage
Re-triaged on
main 97065bac:needs-info, because the report describes two very different situations with the same words, and the code distinguishes them:social.js:176-183namesface_room_auto_send_offas a real per-room switch,:4497only auto-sends a face line whenautoSendFaceLinesucceeds, and:4510-4515refuses unlessheld.autoSendHold === true. A pair that has never set it reads “Waiting for approval” forever, and the owner's Approve is the feature working.autoSendRoomEnvelopeclears the blanketmvp.all_outbound_requires_approvalhold for a room line (:1825,:1867,:2000), and:181-182says explicitly that neither outbound path clearsface_room_auto_send_off. If the pair is a co-seat in one open room and the room's own Auto-send is on, a card here is a bug — in the clearing path, not in the seat.What I need on this issue to decide between them, all of it from the same attempt:
holdReasonandreasons(theface_room_auto_send_offswitch versus a blanket reason);roomId) and whether both Bots are current members of that same open room — co-seat versus 1:1 is the axis Send a shared-room leave while the seat is still reachable #1174/Co-seat shared-group Bot outbound still waits for owner Approve #1175 turn on;#948territory), not the room path.With those four answered this becomes either “working as designed, set the room's Auto-send” (and closes) or an
agent-readybug with a named file. Labels:area:socialadded, because this is Bot Social outbound, not a UI defect.