fix(relay): stop multi-channel HTTP query from narrowing to one UUID - #6648
fix(relay): stop multi-channel HTTP query from narrowing to one UUID#6648BradGroux wants to merge 1 commit into
Conversation
6c709a2 to
100b333
Compare
|
Rebased onto the latest No review comments on this PR. CI will verify the build and test gate. |
100b333 to
6028d2f
Compare
🔐 Codex Security Review
|
|
Rebased onto the latest Still-needed assessment: No upstream commits in the 62-commit window address the same issue. This PR remains needed. Review requests: |
6028d2f to
c7a74d7
Compare
|
Rebased onto current Still needed: Checked all 38 new upstream commits for overlap with this PR's topic. None of the upstream changes address the issue this PR fixes. The PR remains relevant. Verification:
|
c7a74d7 to
a81a1b4
Compare
Rebase and review — 2026-09-03Base commit: Accuracy review: Multi-channel HTTP query still narrows to one UUID. |
a81a1b4 to
8bc9120
Compare
Rebase and review update — Sep 3, 2026Rebased onto latest main ( Accuracy review: Main's multi-channel HTTP query still narrows to a single UUID when multiple channel IDs are requested. The PR's fix to stop the query from collapsing to one channel is still needed. Mergeable status: Confirmed MERGEABLE on GitHub after force-push. |
A POST /query filter with multiple #h values silently returned events from only the lexicographically smallest channel UUID, ignoring all others. The single-filter extract_channel_id_from_filter returned the first parseable UUID from the BTreeSet-ordered #h values, which pinned the SQL to a single channel. The multi-filter variant extract_channel_id_from_filters already had the correct guard — return None when more than one distinct channel appears — but the HTTP bridge path used the single-filter variant without that guard. When extract_channel_id_from_filter returns None, apply_access_scope_to_query replaces the single-channel pin with the caller's full accessible-channel IN-list, and the existing per-event post-check keeps results correct. Closes block#5053. Co-authored-by: Brad Groux <brad@digitalmeld.com> Signed-off-by: Brad Groux <brad@digitalmeld.com> Signed-off-by: Brad Groux <bradgroux@hotmail.com> Signed-off-by: Brad Groux <3053586+BradGroux@users.noreply.github.com>
8bc9120 to
f35e8b4
Compare
Rebase pass — Sep 5, 2025Rebased onto current upstream main ( Rebase resultRebased cleanly onto current main. No conflicts. Still-needed assessmentChecked all 62 new main commits for overlap with this PR's topic. None obsoleted:
Verification
|
1 participant
Summary
A
POST /queryfilter with multiple#hvalues silently returned events from only the lexicographically smallest channel UUID, ignoring all other listed channels. The desktop Workflows screen issues exactly this shape — one filter with all member-channel IDs — so workflows in any channel other than the smallest UUID were invisible.The single-filter
extract_channel_id_from_filterreturned the first parseable UUID from theBTreeSet-ordered#hvalues, which pinned the SQL tochannel_id = <that uuid>. The multi-filter variantextract_channel_id_from_filtersalready had the correct guard — returnNonewhen more than one distinct channel appears — but the HTTP bridge path (build_event_query_from_filter) used the single-filter variant without that guard.The fix gives
extract_channel_id_from_filterthe same multi-channel semantics as the plural variant: returnNonewhen the filter carries more than one distinct channel UUID.apply_access_scope_to_querythen replaces the single-channel pin with the caller's full accessible-channelIN-list, and the existing per-event post-check (filters_match+ accessible-channel check) keeps results correct.Related issue
Fixes #5053.
Testing
None), no channel tag (returnsNone), and duplicate same channel (returns the channel).buzz-relaylibrary test suite: 863 passed, 8 failed (allPoolTimedOut— database-dependent media/admin tests that fail identically on cleanmainwithout a Postgres connection).cargo fmt --checkandcargo clippy -- -D warningspassed forbuzz-relay.