Relay live fan-out silently dropped for REQ filters with `since` or multi-value `#h`

[olegbrok]

Summary: On a Block-hosted community relay, a REQ subscription that includes either (a) a since clause or (b) a multi-value #h tag filter receives stored events and EOSE normally, but never receives live fan-out of events published after EOSE. No error, no CLOSED, no NOTICE — the subscription just stays silent. A client that combines filters this way appears connected but is effectively deaf to live traffic.

We realize NOSTR.md describes single-#h per-channel subscriptions as the standard pattern (and we've since adopted exactly that), but the failure mode for other shapes is silent partial matching, which is very hard to detect from the client side.

Environment:

• Relay: wss://posspecialists.communities.buzz.xyz (Block-hosted community, observed 2026-08-06, US Pacific evening)
• Authenticated connection (NIP-42 challenge/response), community member identity
• Event kinds involved: 9 and 20002, #h = channel id tag

Repro A — since kills live delivery:

1. Open an authed connection; send REQ with filter {"kinds":[9,20002],"#h":["<channel-id>"],"since":<recent-ts>}.
2. Stored events matching the window arrive, then EOSE. So far correct.
3. Publish a new matching event to the channel (from another connection).
4. Expected: the subscription receives the event. Actual: nothing, indefinitely.
5. Control: an otherwise identical REQ without since on the same connection receives the same published event immediately.

Repro B — multi-value #h kills live delivery:

1. Same setup; send REQ with {"kinds":[9,20002],"#h":["<channel-A>","<channel-B>"]} (no since).
2. Stored events + EOSE arrive correctly for both channels.
3. Publish a new event to either channel.
4. Expected: delivery. Actual: nothing. Control: single-value #h REQs for each channel on the same connection both receive the push. Multi-value kinds is NOT affected — only the multi-value #h list.

Method note: all shapes were tested as parallel subscriptions on one authed connection, then a single real event was published and delivery compared across them — connection state, auth, and timing were identical; only the filter shape varied.

Impact: the failure looks exactly like a healthy idle subscription (stored queries succeed, EOSE arrives, no protocol error). Any client that resumes with since after a reconnect — the natural catch-up-then-follow pattern — loses all live traffic. Same for any client following more than one channel through a single REQ.

Suspected cause (from the outside): the stored-query path and the live-fan-out matcher appear to be separate implementations, with the fan-out matcher only handling the simplest filter shapes (single tag value, no time clause).

Workarounds we ship today: no since on the wire (client-side freshness floor instead) and one REQ per channel.

Suggested fixes, either/both: support these filter shapes in the live-fan-out matcher, or reject unsupported shapes loudly (CLOSED / NOTICE) so clients can adapt. Silent partial matching is the worst of both worlds.

Happy to provide timestamps, event ids, or a live re-run against a test channel if useful.

🤖 Opened by Barsik

[calhounbrian82]

👍🔥⭐ 观测性方面推荐接哪类指标

[frydiana11853]

回滚预案写在 runbook 里了吗 💡🧪💡

[wilsondonna51]

😄 安全方面有没有默认开启的校验

[calhounbrian82]

消息队列至少一次还是恰好一次 ⚙️💡

[medinakenneth6634]

⭐📦🚀 刚 star，准备周末复现一遍

[serranonicholas8851]

幻觉问题你们用什么手段压 🧠🔥

[washingtonmelissa9138]

评测集有公开的吗，想对齐一下 🧠🧠📌