[Bug] Workflow send_message @mentions never wake the mentioned agent: author_allowed drops relay-signed workflow events before mention matching
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
**Describe the bug**
A scheduled workflow `send_message` that @mentions an agent never wakes that agent, even though the emitted event is well formed (kind 9, correct `p` tag for the agent, `buzz:workflow` tag). The same agent wakes within seconds when the same channel mention comes from a human or another agent. The daily automation fails silently: the message posts on schedule, the agent never gets a turn, and nothing surfaces the drop.
This is the same root cause makgunay documented in a comment on #2702 (https://github.com/block/buzz/issues/2702#issuecomment-5108048221): in `crates/buzz-acp/src/lib.rs`, `author_allowed` runs before `filter::match_event`, and workflow output is signed by the relay keypair, which is neither the agent's owner nor a sibling with a NIP-OA `auth` tag. Under the default `RespondTo::OwnerOnly` the event is dropped before its `p` tags are ever inspected. Filing it as a dedicated bug so it is visible in triage rather than living only inside a feature request thread; #2702 is the feature ask (silent invocation), this is the defect (documented mention-wake path does not work at all).
**Steps to reproduce**
1. Create a channel workflow with a `schedule` trigger and a `send_message` action whose text @mentions a managed agent running under buzz-acp with default (owner-only) access. Ours:
```yaml
trigger:
on: schedule
cron: "0 2 * * *"
steps:
- id: morning_brief
action: send_message
text: "@Dozer Prepare and post the morning briefing ..."
```
2. Let it fire (or `buzz workflows trigger` it as the workflow creator).
3. Observe the posted event: correct `h` tag, correct `p` tag for the agent, `buzz:workflow=true`, authored by the relay/workflow keypair, no `auth` tag.
4. The mentioned agent never receives a turn. Control: an ordinary owner- or agent-authored @mention in the same channel wakes the same agent in 1-2 seconds.
Ruled out on our deployment before finding the author gate:
- Machine asleep: `pmset -g log` shows the Mac awake at every missed fire (buzz-desktop holds a sleep assertion).
- Harness down: Buzz Desktop and all ACP processes up continuously across two consecutive missed fires.
- Membership: adding the workflow author pubkey as a channel member changes nothing (expected, since the gate is authorization, not membership).
- Mention construction: plain-text `@Name`, valid `p` tag present (so this is not #2686).
Sample failing events on our relay: `b79e5ff09a558839bb54a4b395a1cda8e8e6f28fcd8cfaa2f37661aea4fea1e4` (2026-07-30 02:00:03 UTC), `6c95a35485a0522ba85b17c40c4650dbfb3555c2c2ee98f7217628afbad9ace1` (2026-07-31 02:00:03 UTC), `34dd15128569a3b8eb7d57f4ab7c60acd53d881827dfb56ffa375c61f302e0e6` (manual trigger, 2026-07-31 04:07:08 UTC). All three: zero wakes. Tags on each: `[["p",""],["h",""],["buzz:workflow","true"]]`.
**Expected behavior**
A workflow-emitted channel message with a valid `p` tag for an agent should wake that agent, matching the wake contract stated in `crates/buzz-relay/src/workflow_sink.rs` ("so mentioned agents are woken (wake is `p`-tag gated)"). makgunay's suggested direction on #2702 seems right: for relay-signed events carrying `buzz:workflow`, resolve the effective author from the workflow's owner attribution (ideally an explicit `buzz:workflow_owner` tag) before applying `author_allowed`, so owner-only semantics are preserved per owner without trusting the shared relay key.
**Version and platform**
- Buzz version: 0.5.2
- OS: macOS (Darwin 25.5.0), Apple Silicon
**Logs / additional context**
- Two independent agents on this deployment (the target agent and the investigating agent) reproduced both halves: workflow mention drops silently, owner/agent-authored mention wakes instantly.
- `strings` on the shipped buzz-acp binary shows the gate messages ("NIP-OA auth tag verification failed", "owner resolved from BUZZ_AUTH_TAG"), consistent with the source analysis on #2702.
- Related: #2702 (feature: silent agent invocation), #2686 (markdown-wrapped mentions emit zero p tags), #3697 (closed: dispatch_agent step), #3638 (owner p-tag wakes owner agent on every send_message; that owner attribution p tag at index 0 is presumably the one a fix would resolve the effective author from).
Contributor guide
Research direction
Start in crates/buzz-acp/src/lib.rs by tracing author_allowed and its ordering relative to filter::match_event, then compare the wake contract in crates/buzz-relay/src/workflow_sink.rs. Reproduce the scheduled send_message case and inspect related issue context; done means a relay-signed workflow event with a valid agent p tag wakes that agent while owner-only authorization remains enforced.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- authorization, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100