fix(relay): read a channel's creation once, not per metadata version - #3244

Problem

Each membership change makes the relay republish the channel's kind:39000 metadata, re-signed and so with a new event id, to every online member. Members get it because every joined channel sits in a batched live route over CHANNEL_KINDS.

On each 39000, applyDiscovery calls readCreations. That issues a background kind:9007 read for the channel's creator proof (huddle detection). The read was deduplicated by metadata version, so every republish missed the dedupe. Each single-person add made every online member send another /query.

Cost per run of adds: members online × adds. A bulk run of single-person adds to large channels turned this into a relay-wide burst of 9007 reads.

Change

readCreations now deduplicates background reads per channel instead of per version. A channel's creator (P) and creation receipt never change.

• A read that finds the receipt is final.
• A read that finds none, or fails, leaves a negative entry. A later metadata version retries once its backoff has passed, measured on the monotonic clock (performance.now()). The backoff starts at a minute and doubles to an hour, with jitter up to 1.5×.
• No miss is treated as final. A replica can lag at any read, and 39000 created_at reflects replacement order, not elapsed time. A Huddle whose receipt was missing therefore still gets classified once the receipt is readable.
• A cancelled read clears its entry, so the next version reads again right away: it learned nothing, so it doesn't back off. (Before, every error cleared the entry.) A read cut at its filter limit still retries on the next version, unchanged.
• Strong resolution (consistency: "strong") still bypasses the dedupe. Huddle invites resolve this way.
• A version that arrives while a read is in flight shares that read.

Background reads per client per membership change go from 1 to 0 once a channel's proof is found. Until then they are bounded by the backoff rather than by the rate of adds, which also covers a relay that is failing these reads (RPR: design every relay-facing path for the whole fleet at once).

Huddle classification

A Huddle is recognized from its creation receipt. The creator (right after creating) and invitees (on the member-added notice) resolve the room with strong consistency, which bypasses this dedupe and backoff, so the main paths are unchanged.

The difference is only on the background path, when its first read misses the receipt (replica lag or a failed read):

• Before: the next metadata version (the next join or rename) read again, usually seconds later.
• After: the next read waits until the backoff (60–90s) has passed and another version arrives.

In that window the room shows as an ordinary private channel instead of a Huddle under its parent. Neither version has a timer: with no further version, the room stays unclassified until the next strong resolve or restart, as before.

Rollout

Client-only, no flag: this takes effect as clients upgrade. A relay-side database pool increase is the immediate mitigation for the bursts; this change removes their source.

• Success signal: the relay's rate of kind:9007 /query reads, and database pool wait time during bulk channel adds, before and after the release.
• Rollback: revert.

What got simpler

CreationRead replaces its per-version key with a per-channel entry plus a miss count and retryAt. Retries are driven by events, so there are no timers or new lifecycle owners.

Tests

New tests in store.test.ts › creator proof reads drive the live 39000/39002 republish path, with a controlled clock and no jitter.

• reads a channel's creation once…:

  • a failed read waits out its backoff
  • an in-flight read is shared
  • after a real receipt, later republishes issue no read, even a day later

• retries a missing creation with backoff until it arrives:

  • an old channel's first sighting misses twice
  • no read at 59.999s; it reads at 60s, then again at 120s once the backoff has doubled
  • the receipt then classifies the room as a Huddle with its parent

• lets the next version read again after a cancelled creation read: a cancelled read issues a new read on the next version without advancing the clock.

Discrimination: the first two fail on base and on the previous revision's store. The cancelled-read test fails if a cancel backs off like a miss.

🤖 Generated with Claude Code

buzz-review-completed