block / block/buzz

[Bug] Workflow @agent-name does not resolve when agent profile display_name differs, emitting no p tag and never waking ACP

Open
#5,371 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
Rust
Stars
32.7k
Forks
4.3k
Avg merge
1d 13h
Merged PRs (30d)
253

Description

## Reproduction

A scheduled workflow in a channel contains a normal agent mention:

```yaml
steps:
- action: send_message
text: "@OMP perform the scheduled check"
```

The channel member is the agent named `OMP`, but its Nostr user profile has `display_name: "OMP-Mac"` (the platform-created runtime/profile label). The workflow is accepted and the relay posts the kind:9 message, but it contains no `p` tag for the agent:

- text contains `@OMP`
- event contains `buzz:workflow=true`
- event contains the channel `h` tag
- event is relay-signed
- event has no `p=`

ACP agent wake is `p`-tag gated, so the agent never receives the workflow task and no result is produced. This reproduced on a hosted channel on 2026-08-09.

## Root cause

`crates/buzz-relay/src/workflow_sink.rs::resolve_mention_pubkeys` resolves workflow text against `users.display_name` only. It has no awareness of the agent's configured/canonical name. Interactive client mention composition resolves an agent selection into a pubkey, but workflow YAML stores only free text and re-parses it later, so `@OMP` and `OMP-Mac` drift apart.

This is related to #2686 (workflow sink has a divergent mention parser), but is a distinct identity-resolution failure: even plain `@Name` text at a valid boundary fails when the configured agent name differs from its profile display name.

## Expected behavior

A workflow addressed to the channel agent's canonical name should emit the same `p` tag as an interactive mention and wake that agent, regardless of a runtime/profile display-name suffix.

## Suggested direction

Use one canonical mention-resolution service for both interactive composition and workflow execution. For workflow text, resolve exact channel-scoped aliases from both:

1. the user display name; and
2. the agent's configured/canonical name.

Keep the current fail-closed behavior for ambiguous aliases: if an alias maps to multiple pubkeys, emit no `p` tag and return a visible workflow validation/error result instead of silently posting an unwakeable task. Add regression coverage for `agent name != profile display_name`, including `OMP` / `OMP-Mac`.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.