Self-hosted community on current main (relay image digest b4148c43…, Desktop latest release, closed relay: auth token + membership required). Four related findings from a day of production use — three have minimal repros and local patches (diff available, happy to open PRs).
1. /query bridge drops multi-value #h filters → Desktop Workflows tab always empty
extract_channel_from_filter (crates/buzz-relay/src/api/bridge.rs) only resolves the channel when the #h filter has exactly one value (vs.len() == 1), returning None otherwise — the query then yields an empty result set silently. The Desktop's Workflows overview batches all member channels into a single filter (get_channels_workflows, "replaces the per-channel fanout"), so the tab permanently renders "No workflows yet" even though the relay stores and executes the workflows.
Repro (NIP-98-signed POST /query):
{"kinds":[30620],"#h":["<ch1>"]} → 200, N results
{"kinds":[30620],"#h":["<ch1>","<ch2>"]} → 200, 0 results
NIP-01 defines multiple values in a tag filter as OR. Local fix: expand a multi-value #h filter into one single-channel filter per value before processing, so every downstream membership/authorization check runs per channel unchanged.
2. Deleting a workflow leaves its kind:30620 event alive → ghost cards in the list
The NIP-09 deletion side-effect for KIND_WORKFLOW_DEF (handlers/side_effects.rs) removes the engine row (delete_workflow_for_owner) and invalidates the cache, but never touches the stored 30620 event. Since the Desktop lists workflows from those events, deleted workflows keep showing forever (and, combined with finding 1's fix, reappear after every refetch). Local fix: soft-delete (deleted_at = now()) the definition events for the deleted workflow's d tag in the same side-effect.
3. Workflow update by a plain member is accepted then silently discarded
A kind:30620 update signed by a member who is not the workflow owner (nor admin) gets accepted: true from the relay, but neither a new event version nor an engine-table update is materialized. The client believes the edit succeeded; execution keeps using the old definition. Expected: either reject with an explicit error or materialize. (Observed while an agent identity tried updating a workflow it didn't own; owner/admin updates work.)
4. Reaction to a social post panics the relay task → client sees 502
Reacting (kind 7) to a channel-less kind:1 social post hits channel_id.expect("reaction path has channel") at handlers/ingest.rs:2733 — the comment above it says "channel_id is always Some here", which is false for social reactions:
thread 'tokio-rt-worker' panicked at crates/buzz-relay/src/handlers/ingest.rs:2733:51
The reaction IS persisted (panic happens in post-persist tracing), the client gets 502 Bad Gateway, and every retry panics again. Local fix: channel_id.unwrap_or(Uuid::nil()) for the trace label.
Combined patch for 1, 2 and 4 (applies on main @ ac4fa13) is running in our production relay; glad to split it into PRs if useful. Workflows experiment is enabled under Settings → Experiments. Thanks for Buzz — the agent-native design is excellent to operate.
Self-hosted community on current
main(relay image digestb4148c43…, Desktop latest release, closed relay: auth token + membership required). Four related findings from a day of production use — three have minimal repros and local patches (diff available, happy to open PRs).1.
/querybridge drops multi-value#hfilters → Desktop Workflows tab always emptyextract_channel_from_filter(crates/buzz-relay/src/api/bridge.rs) only resolves the channel when the#hfilter has exactly one value (vs.len() == 1), returningNoneotherwise — the query then yields an empty result set silently. The Desktop's Workflows overview batches all member channels into a single filter (get_channels_workflows, "replaces the per-channel fanout"), so the tab permanently renders "No workflows yet" even though the relay stores and executes the workflows.Repro (NIP-98-signed
POST /query):NIP-01 defines multiple values in a tag filter as OR. Local fix: expand a multi-value
#hfilter into one single-channel filter per value before processing, so every downstream membership/authorization check runs per channel unchanged.2. Deleting a workflow leaves its kind:30620 event alive → ghost cards in the list
The NIP-09 deletion side-effect for
KIND_WORKFLOW_DEF(handlers/side_effects.rs) removes the engine row (delete_workflow_for_owner) and invalidates the cache, but never touches the stored 30620 event. Since the Desktop lists workflows from those events, deleted workflows keep showing forever (and, combined with finding 1's fix, reappear after every refetch). Local fix: soft-delete (deleted_at = now()) the definition events for the deleted workflow'sdtag in the same side-effect.3. Workflow update by a plain member is accepted then silently discarded
A
kind:30620update signed by a member who is not the workflow owner (nor admin) getsaccepted: truefrom the relay, but neither a new event version nor an engine-table update is materialized. The client believes the edit succeeded; execution keeps using the old definition. Expected: either reject with an explicit error or materialize. (Observed while an agent identity tried updating a workflow it didn't own; owner/admin updates work.)4. Reaction to a social post panics the relay task → client sees 502
Reacting (kind 7) to a channel-less kind:1 social post hits
channel_id.expect("reaction path has channel")athandlers/ingest.rs:2733— the comment above it says "channel_id is always Some here", which is false for social reactions:The reaction IS persisted (panic happens in post-persist tracing), the client gets
502 Bad Gateway, and every retry panics again. Local fix:channel_id.unwrap_or(Uuid::nil())for the trace label.Combined patch for 1, 2 and 4 (applies on
main@ac4fa13) is running in our production relay; glad to split it into PRs if useful. Workflows experiment is enabled under Settings → Experiments. Thanks for Buzz — the agent-native design is excellent to operate.