Summary
On a hosted Buzz relay (*.communities.buzz.xyz, checked 2026-08-02), workflows with trigger: on: message_posted never execute, while webhook-triggered, scheduled, and manually-triggered workflows on the same relay/channel run fine. Because run history is also invisible to clients (see below), a dead trigger is indistinguishable from a working one, which makes this very hard for users to self-diagnose.
Environment
- Hosted relay on
communities.buzz.xyz (deployed version unknown to me — NIP-11 doc carries no version field)
- Buzz Desktop 0.5.3 (macOS) and
buzz CLI from the same bundle
- Could not verify against OSS HEAD locally (no Docker on this machine), so this may be deployment drift rather than a bug at
main — flagging either way since hosted users can't tell the difference.
Repro (CLI, ~2 min)
- As a channel member, create a minimal message-triggered workflow with an observable in-channel action:
name: engine_probe
enabled: true
trigger:
"on": message_posted
filter: 'str_contains(trigger_text, "probe-phrase-7793")'
steps:
- id: react
action: add_reaction
emoji: eyesbuzz workflows create --channel <uuid> --yaml "$(cat probe.yaml)" → accepted, workflow id returned.
- Post a kind:9 channel message containing
probe-phrase-7793.
- Wait. Expected: 👀 reaction on the message (via the relay workflow sink). Actual: nothing (checked with
buzz reactions get --event <id> over ~10 minutes).
What DOES work on the same relay
- Manual trigger:
buzz workflows trigger --workflow <id> on the same probe workflow → accepted, run_id returned.
- Webhook-triggered workflows: a
trigger: on: webhook workflow with a send_message step has fired repeatedly on this relay (relay-signed kind:9 messages with the buzz:workflow tag are present in channel history).
- Workflow saves, updates, deletes, and list queries all behave normally.
- The SEC-006 gates behave as documented (e.g.
forbidden: workflows with call_webhook actions require the owner or admin role for non-admin authors) — the probe above deliberately avoids call_webhook and is owned by a member whose role passes owner_authority_allows(role, false).
Where I looked in the source
dispatch_persistent_event (crates/buzz-relay/src/handlers/event.rs:533) spawns workflow_engine.on_event(...) for stored kind:9 events, and WorkflowEngine::on_event reads enabled workflows from the DB (10s cache) before evaluating trigger_matches_event / should_fire_workflow. I couldn't find a path where the probe above should be skipped, which is why I suspect the hosted deployment predates or diverges from this wiring — but I can't confirm the deployed version.
Related papercut that made this much worse
buzz workflows runs always returns [] by design (crates/buzz-cli/src/commands/workflows.rs:63 — runs live in the workflow_runs table and kinds 46001–46003 are never emitted), and the Desktop equivalent returns a hard-coded empty list (desktop/src-tauri/src/commands/workflows.rs, get_workflow_runs TODO). So users have zero signal on whether any workflow ever fired. Even just emitting run-started/run-failed events (or a REST read) would have made this a 5-minute diagnosis instead of an afternoon.
Happy to provide more detail or run further probes on the hosted relay if useful.
Summary
On a hosted Buzz relay (
*.communities.buzz.xyz, checked 2026-08-02), workflows withtrigger: on: message_postednever execute, while webhook-triggered, scheduled, and manually-triggered workflows on the same relay/channel run fine. Because run history is also invisible to clients (see below), a dead trigger is indistinguishable from a working one, which makes this very hard for users to self-diagnose.Environment
communities.buzz.xyz(deployed version unknown to me — NIP-11 doc carries no version field)buzzCLI from the same bundlemain— flagging either way since hosted users can't tell the difference.Repro (CLI, ~2 min)
buzz workflows create --channel <uuid> --yaml "$(cat probe.yaml)"→ accepted, workflow id returned.probe-phrase-7793.buzz reactions get --event <id>over ~10 minutes).What DOES work on the same relay
buzz workflows trigger --workflow <id>on the same probe workflow →accepted,run_idreturned.trigger: on: webhookworkflow with asend_messagestep has fired repeatedly on this relay (relay-signed kind:9 messages with thebuzz:workflowtag are present in channel history).forbidden: workflows with call_webhook actions require the owner or admin rolefor non-admin authors) — the probe above deliberately avoidscall_webhookand is owned by a member whose role passesowner_authority_allows(role, false).Where I looked in the source
dispatch_persistent_event(crates/buzz-relay/src/handlers/event.rs:533) spawnsworkflow_engine.on_event(...)for stored kind:9 events, andWorkflowEngine::on_eventreads enabled workflows from the DB (10s cache) before evaluatingtrigger_matches_event/should_fire_workflow. I couldn't find a path where the probe above should be skipped, which is why I suspect the hosted deployment predates or diverges from this wiring — but I can't confirm the deployed version.Related papercut that made this much worse
buzz workflows runsalways returns[]by design (crates/buzz-cli/src/commands/workflows.rs:63— runs live in theworkflow_runstable and kinds 46001–46003 are never emitted), and the Desktop equivalent returns a hard-coded empty list (desktop/src-tauri/src/commands/workflows.rs,get_workflow_runsTODO). So users have zero signal on whether any workflow ever fired. Even just emitting run-started/run-failed events (or a REST read) would have made this a 5-minute diagnosis instead of an afternoon.Happy to provide more detail or run further probes on the hosted relay if useful.