Files
buzz/crates/buzz-db
Will Pfleger e645918c63 fix(relay): match pushed-down tags by position, not containment (#8335)
🤖 The relay pushes several tag filters into SQL as JSONB containment
(`tags @> [[name, value]]`). Containment ignores element position, so a
tag like `["x","e",<id>]` or `["meta","t",v]` satisfies `#e:[<id>]` or
`#t:[v]`, and `#t:["t"]` matches `["t","other"]`. Because the predicate
runs before `LIMIT`, a newer event that only matches by containment can
take a `limit: 1` slot; the exact NIP-01 post-filter then drops it and
the real match is never returned. Where no post-filter follows, the
decoy is returned or counted outright.

`push_exact_tag_match` in `buzz-db/src/store/event.rs` keeps containment
as the GIN-indexed prefilter (one array-bound `tags @> ANY(...)`, so the
e-tag planner shape is unchanged) and adds a positional `EXISTS (...
tag->>0 = name AND tag->>1 = ANY(values))`. It now backs every
`EventQuery` tag pushdown:

| Pushdown | Before | Effect of over-match |
|---|---|---|
| `#e` (`e_tags`, query and COUNT) | containment | REQ `limit` slot
theft; COUNT has no post-filter and counted decoys; thread aux closure
returned decoy reactions/replies |
| artifact `#d` (`d_tag_values`) | containment | `limit` slot theft on
NIP-AR identity lookups |
| `custom_tag` (bridge `#buzz-channel`) | containment | no post-filter:
a decoy project/repository was returned for its channel |
| shared-gated visibility (`shared_gated_reader`) | containment of
`["shared","true"]` | a private event tagged `["x","shared","true"]`
took a page slot before `event_visible_to_reader` dropped it, so the
page came back short. Never a visibility leak: the post-filter stays in
place |

**Bridge `/count` honors `#buzz-channel`.** `POST /query` scoped
project/repository reads by `#buzz-channel`, but `POST /count` ignored
it, so a count for one channel counted matching projects in every
channel the reader can see. `/count` now sets the same `custom_tag` on
both its channel-scoped and access-scoped paths, and the COUNT SQL
builder pushes `custom_tag` down exactly like the query builder, so
`/count` and `/query` select the same events on both the fast count and
the post-filtered fallback.

Left unchanged: the retention-free purge predicate for mesh status
(`tags @> [["k","buzz-mesh-status"]]`). It mirrors the migration 0019
trigger, has no `LIMIT`, and only affects how the author's own deleted
event is purged. REQ `#t` outside group-state kinds is still
post-filtered only.

---------

Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz>
2026-10-15 00:37:11 +00:00
..