Repository navigation
A member's @mention of the group admin is sometimes never delivered: the round ends without the admin's turn #804
Description
What happens
In the group FlyBot 交付组 the admin Bot (Chief) is sometimes not called when a member writes @Chief in a message. The round simply ends and the mention is silently dropped. The user noticed it as "Dev3 mentioned you and you said nothing".
Two timelines in the same group, same members, same @ form
A — the mention is honoured. Dev3 ends a message with
@Chief 我空了。手上只有一件在等：#800（tip 16c2945f）还没派审…
and the very next turn is Chief's, which answers it with a dispatch (#799 is handed to Dev3). Nothing is lost.
B — the mention is dropped. A round starts with Chief's message ("三项核对都已完成…"), then Triage, Dev4 and Dev3 speak in that order. Dev3's last message ends with
@Chief 我空了。手上只剩等：#802 需要派审，#800 … 的 PASS 也还压在结算锁上
No Chief turn follows. The group is silent for 10m39s until the user asks "为什么 Dev3 @ Chief 但是你不说话". There is no error, no notice, nothing in the transcript to say the mention was not delivered.
The difference between A and B
- In A the admin had not yet spoken in that round when the mention arrived.
- In B the admin had already posted once, and the mention came from the last speaker of the round.
- A third case exists where the admin had spoken, a member then wrote
@Chief 收到…, and the admin was called again — so "admin already spoke" alone does not explain B.
Hypotheses worth checking first
- The admin is only queued for a round if it has not spoken yet; a later mention from a member is not added to the speaker list.
- The round's speaker list is computed when the round starts, so a mention appended afterwards is never delivered.
- The @-handling for the admin role differs from the handling for a plain member, and the difference depends on who is the last speaker.
Why it matters
The dropped mention was a Bot reporting that it was idle and asking for work. Silence means that Bot stays idle, the coordinator believes it is still busy, and the user has to notice by hand. This is the exact failure mode the group's "when you are idle, say so and @chief" rule depends on — the rule is only as good as the delivery.
Acceptance
- A member's
@Adminin a group message always results in the admin being called in that round, or an explicit, visible failure (a notice in the group or an error to the sender) — never a silent drop. - A regression test covers the shape that failed here: the admin has already posted in the round, then a member mentions the admin as the round's last message — the admin runs.
- The same test covers the case where the mention is not the last message.
Activity
Birfy commentedon Oct 23, 2026
Triage:
bug | area:automation,agent-ready. The two timelines and the third counter-example are enough to treat this as a defect, not a policy: the same@Chiefform is honoured in A, and in the third case the admin spoke and was still called again — so "the admin gets one turn per round" is not a rule that explains the data.It is also the failure mode the whole delivery loop stands on: the one message that says "I am idle, give me work" is exactly the message that can vanish, and the coordinator then believes the member is still busy.
Expected behaviour, in checkable terms:
@Adminin a group message always causes the admin's turn in that round — including when the admin has already posted in the round, and including when the mention is the round's last message. If delivery is ever impossible, the sender learns it in the group (a notice or an error) instead of nothing happening.fd205c40with the B shape (admin has spoken, then a member mentions the admin as the last message), and one more case covers a mention that is not the last message.Scope: the group round's speaker list and the @-handling for the admin role. If the current round model genuinely cannot express "admin called again", stop and say so — that is a design change and belongs to the owner, not to this PR. Do not touch the mention parser's copy, and do not special-case the name
Chief: the rule is about the admin role, whichever Bot holds it.Kill conditions: drop the mention when the admin already spoke → the B test fails; queue the admin unconditionally on every member message → the "two turns" test fails; handle only the last-message shape → the non-last case fails; hard-code
Chief→ a test with the admin role held by another Bot fails.Birfy commentedon Oct 23, 2026
Claimed by Dev2. Branch:
fix/804-admin-mention-roundon Birfy/FlyBot (base61a6af6f); PR will be opened on the fork and will reference this issue by full name.I will first pin the failure with a test on the group relay (the admin has posted once in the round, then a member's
@Adminarrives as the round's last message), then fix whatever makes that mention get dropped.fix(groups): a member's @Admin is never dropped by the per-member tur…
fix(groups): a member's @Admin is never dropped by the per-member tur…
Birfy commentedon Oct 23, 2026
Landed in the fork as
28497253(#27, squash). Closed by the cross-repositoryFixesline when that pull request merged; the state labelsagent-working/agent-prwere cleared here because a closed issue carries history, not workflow state.