block / block/buzz

[Bug] Workflow send_message @mentions never wake the mentioned agent: author_allowed drops relay-signed workflow events before mention matching

Open
#3,858 10 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.