relay: multi-value #h filters collapse to lexicographically-first channel (Workflows overview shows empty)

[leesalminen]

Summary

The relay's /query (HTTP bridge) and REQ paths mishandle a filter with multiple distinct #h values: instead of Nostr's OR semantics ("match any listed channel"), the query silently collapses to the lexicographically-first channel UUID. Every other listed channel's events are dropped.

User-visible impact: the Desktop Workflows overview screen is empty for essentially everyone. get_channels_workflows batches all member-channel ids into one #h filter (desktop/src-tauri/src/commands/workflows.rs, whose comment asserts "A nostr #h filter matches ANY of its listed values") — but the relay only returns workflows for whichever channel UUID sorts first, typically a DM channel with none.

Root cause

Two channel extractors disagree, and the bridge catchall composes them into a contradictory query:

• extract_channel_id_from_filter (crates/buzz-relay/src/handlers/req.rs — singular-filter variant) returns the first parseable #h value even when several are present (for val in tag_values { ... return Some(id) }). Filter tag values live in a BTreeSet, so "first" = lexicographic minimum.
• extract_channel_from_filter (crates/buzz-relay/src/api/bridge.rs) correctly requires vs.len() == 1 and returns None for multi-value filters.

In the bridge catchall (query_events_authed), build_event_query_from_filter uses the first extractor → query.channel_id = Some(<first-sorted id>), then apply_access_scope_to_query is passed the second extractor's None → also sets query.channel_ids = accessible_channels. Resulting SQL (captured via log_statement=all):

SELECT ... FROM events
WHERE community_id = $1 AND deleted_at IS NULL
  AND channel_id = $2                                   -- first-sorted #h value
  AND (channel_id IS NULL OR channel_id IN ($3,$4,$5))  -- access scope
  AND kind IN ($6) ...

The channel_id = $2 clause pins the whole query to one channel.

Note the plural WS-subscription variant extract_channel_id_from_filters already handles this correctly ("Multiple distinct channel IDs — fall back to global"); the singular variant predates that rule.

Repro (any relay, any community)

1. Create workflows in channel A (id 57e6...). Confirm single-channel query returns them:
   POST /query [{"kinds":[30620],"#h":["57e6..."]}] → N events ✅
2. Add a second channel id that sorts before A:
   [{"kinds":[30620],"#h":["4e18...","57e6..."]}] → [] ❌
3. Add a second channel id that sorts after A:
   [{"kinds":[30620],"#h":["57e6...","6254..."]}] → N events (only A's) — confirms first-sorted collapse.

buzz_core::filter::filters_match implements #h OR correctly, so the in-memory post-filter is not the problem — rows never come back from SQL.

Suggested fix

Make extract_channel_id_from_filter return None when the filter carries multiple distinct parseable #h values (mirroring extract_channel_id_from_filters), so the access-scope path takes over and filters_match enforces the per-event #h OR check. Alternatively push all #h values into SQL as an IN list. Either way, a regression test: multi-#h query must return events from every listed accessible channel.

Happy to send a PR for either shape.

[taehalim]

Great writeup — the repro and the two-extractors analysis made this quick to pin down. I went with the first shape you suggested: the singular extractor now returns None on multi-#h (mirroring extract_channel_id_from_filters), so the access-scope path takes over and filters_match enforces the per-event OR. Added an e2e regression that posts to two channels and asserts both come back from /query and /count. PR: #2452. Happy to adjust if you'd already started on a patch.

[ngavelek]

Independent reproduction on the production Buzz relay:

• Buzz Desktop v0.4.26 on macOS 26.5.2 (25F84).
• The Workflows overview showed “No workflows yet.”
• Creating a valid scheduled workflow was accepted and the dialog closed normally, but the overview remained empty after refresh/restart.
• A single-channel CLI read (buzz workflows list --channel <redacted-channel-id>) immediately returned the newly created, enabled kind 30620 workflow definition.
• Repeating the Desktop create because the first workflow was invisible produced a second distinct workflow ID, so this UI failure can silently create duplicate active schedules.
• The duplicate and old/test workflow definitions were successfully deleted through the CLI; one intended definition was then read back successfully.

This behavior strongly matches the batched multi-#h lookup failure described here. A single-channel CLI query is a workable temporary path, but Desktop users can’t reliably discover or manage what they created and may unknowingly create duplicate automations.

No private channel IDs, identity keys, or workflow content are included here. I can retest the Desktop overview against a patched build if useful.

[kpex-sd]

Independent reproduction on a self-hosted relay:

• Buzz Desktop 0.5.2 on macOS.
• Multiple enabled workflows exist in the workflow database and have corresponding signed kind 30620 definition events.
• The workflows remain operational server-side.
• Buzz Desktop displays “No workflows yet.”
• Refreshing the page, restarting Desktop, and performing a healthy relay restart do not restore the list.

This appears consistent with the multi-value #h lookup failure described in this issue. I can retest the Workflows overview against the patched build from PR #2452 if useful.

No relay hostname, organization name, channel names or UUIDs, identity keys, public keys, IP addresses, workflow contents, or cloud-account information are included in this report.

[josephwasily]

Confirming this on Desktop 0.5.3, on a self-hosted community relay — still happening ten days after this was filed.

What I saw, in case the extra data points help:

• Enabled the workflows preview feature under Settings → Experiments. The tab shows up fine, and it's completely empty.
• I have several workflow definitions in one channel. A single-channel query returns them all, exactly as in your step 1. So the events are definitely there and readable.
• I then created a brand new workflow from Desktop's own Create Workflow dialog, thinking my own would at least show up. It didn't. Which lines up with your explanation — the overview still batches every member channel into one #h filter, so it doesn't matter who owns the workflow or which channel it's in, it only ever looks at whichever channel UUID happens to sort first.

One thing that might be worth noting for prioritising: as far as I can tell there's no way to work around this from the UI. useChannelWorkflowsQuery in desktop/src/features/workflows/hooks.ts does the single-channel query that isn't affected by this, but nothing calls it — the overview screen is the only entry point into workflows, and it's the one that batches. So for now the feature is effectively unreachable in Desktop unless your channel happens to win the sort.

Everything still works through the CLI, which sends one channel at a time, so this really does look like exactly the collapse you described rather than anything else.

Happy to test a fix if you get one up.