[BUG]Workflow is created and runs, but is missing from the Workflows list on a self-hosted relay

[ThisisBankole]

Summary

A webhook workflow can be created successfully on a self-hosted Buzz relay and runs correctly, but Buzz Desktop continues to show an empty Workflows page (No workflows yet).

Environment

• Buzz Desktop: v0.4.22
• Relay: self-hosted Docker deployment
• Relay URL: custom wss://… domain behind Cloudflare Tunnel
• Channel: a newly created channel

Steps to reproduce

1. Connect Buzz Desktop to a self-hosted relay.
2. Create a channel.
3. Open Workflows and create a workflow for that channel:
   • Trigger: webhook
   • Action: send_message
   • Channel override: the channel’s UUID
4. Save the workflow.

Actual behavior

• The create flow succeeds and shows a webhook URL plus X-Webhook-Secret.
• Calling the webhook successfully posts messages into the selected channel.
• Refreshing the Workflows page and fully restarting Buzz Desktop still shows No workflows yet.

Expected behavior

The newly created workflow should appear in the Workflows list and be available to view or edit.

Additional evidence

The relay confirms that the workflow exists and is enabled:

• A workflow database record exists with the expected channel ID.
• A signed kind 30620 workflow-definition event exists with the expected d and h tags.
• The webhook executes successfully and posts its send_message action to the channel.

This appears to be a Desktop workflow-list/read issue rather than workflow creation or execution failing.

Impact

The workflow is operational, but it cannot be managed through Buzz Desktop after creation.

[AaronGoldsmith]

Root cause confirmed on current main

This is reproducible on hosted relays too, so it is not specific to self-hosting, webhooks, or Cloudflare Tunnel. The workflow exists and can be returned by a channel-scoped CLI query, while Desktop shows No workflows yet.

The failure is in Desktop's batched multi-channel workflow query:

1. WorkflowsView collects all member channel IDs, sorts them, and calls getChannelsWorkflows(channelIds) (desktop/src/features/workflows/ui/WorkflowsView.tsx:79-103).

2. The Tauri command sends one Nostr filter with every ID in a multi-value #h tag (desktop/src-tauri/src/commands/workflows.rs:69-97):

   {"kinds":[30620],"#h":["channel-a","channel-b","..."]}

3. Relay query conversion does not preserve multi-value #h. extract_channel_id_from_filter returns the first parseable UUID, and build_event_query_from_filter turns that into one channel_id SQL predicate (crates/buzz-relay/src/handlers/req.rs:737-745,841-853).

4. The HTTP bridge executes that narrowed DB query before applying the full NIP-01 filter (crates/buzz-relay/src/api/bridge.rs:1203-1283). Rows from every other requested channel are therefore never candidates for post-filtering.

Because Desktop sorts the IDs first, the Workflows page effectively lists workflows only from the lexicographically first member channel. If that channel has no workflows, the page incorrectly displays No workflows yet, even when workflows exist in other member channels.

Regression

The batched query was introduced in commit 2cc0eb53968ec6281be0e6778a06ea18e044395e / PR #1641, replacing the prior Promise.all of one get_channel_workflows query per member channel. The implementation comment says a multi-value Nostr #h filter matches any listed channel, which is correct at the protocol level, but the relay's SQL pushdown currently narrows it to one channel.

Independent production evidence

For channel fc76446d-6c74-4401-bad3-f7fc44471914, a per-channel query returns workflow d7719de3-7ad9-4d86-8e0c-297534640746, while the Desktop Workflows page is empty:

buzz workflows list --channel fc76446d-6c74-4401-bad3-f7fc44471914

[{
  "workflow_id": "d7719de3-7ad9-4d86-8e0c-297534640746",
  "pubkey": "9cc2b8b0ed055892ccb72fbbfddd22dc504ebd70fb5490e20f3934df86c0cdda"
}]

This is separate from #1593 / PR #2242: those cover workflow deletion and orphan reconciliation, not workflow listing.

Suggested fixes

Immediate, low-risk Desktop fix

Restore one query per channel (the pre-#1641 behavior), or send one filter object per channel in a single /query request. Either avoids the broken multi-value #h pushdown while preserving complete results.

Relay fix

Represent multiple #h values as a channel_ids predicate rather than selecting the first UUID. Add regression coverage proving that a filter with workflows in channels A and B returns both, including the case where A has no workflow and B does.

[taehalim]

Likely the same root cause as #2385 — the desktop Workflows overview batches all member channels into one multi-value #h filter, which the relay collapses to a single channel (lexicographically-first UUID), so every other channel's kind:30620 definitions are dropped from the list even though the workflows themselves run fine. Fix pending in #2452; once merged this list should populate.

[Chessing234]

Desktop workaround in #2503 — one #h filter per channel (complements #2452).