Files
buzz/crates
Luke Tornquist 16eb0b6685 feat(buzz-db): run push enqueue and channel TTL refresh in app code (#8135)
## Summary

Moves the producer side of the two event follow-up triggers into
application code. The triggers stay in place, so both producers run
until a later change drops the triggers after this ships to every pod.

Builds on #8130 (`AdmittedTx`). Refs BUZZ-176.

### Push match enqueue

New `store::event_follow_up::enqueue_push_match` replaces the
`events_enqueue_push_match` trigger
(`schema/functions/enqueue_push_match_job.sql`, migration 0023) and
matches it exactly:

- Same kind allowlist (9, 40002, 45001, 45003), now `PUSH_MATCH_KINDS`.
- Takes the same SHARED `buzz_push_gate:<community>` advisory lock as
its own statement, so under READ COMMITTED the lease check gets a
snapshot taken after the lock is granted. Lease activations still take
it EXCLUSIVE in `push.rs`.
- Same lease predicate (`active AND endpoint_enabled AND expires_at >
now`), then `INSERT push_match_queue ... ON CONFLICT DO NOTHING`.
- Fails closed: any error rejects the event, as the trigger did.

It runs right after the INSERT, only when the insert affected a row. The
consumer side (claims, `lease_until`, attempts, reaper) is already
app-owned and is unchanged.

### Channel TTL refresh

`AdmittedTx` now records every channel that received an event (except
kind 9007 and channel-less events). `AdmittedTx::commit()` refreshes
their `ttl_deadline` as the last statement before COMMIT, which keeps
the commit-time behavior of the deferred `events_refresh_channel_ttl`
trigger (migration 0024):

- One savepoint per channel, in sorted order, under the same SHARED
`buzz_channel_ttl:<community>:<channel>` lock.
- Runs the same `UPDATE` with the same `archived_at`/`deleted_at`
filters as its own statement after the lock, so its snapshot follows the
lock grant. Its `ttl_seconds IS NOT NULL` qual filters a permanent
channel before any tuple lock, so a permanent channel's row is never
locked. An ephemeral channel's row lock is held through the remaining
refreshes and the COMMIT round trip (the trigger held it only inside
COMMIT).
- Lock keys come from one builder per protocol
(`channel::channel_ttl_lock_key`, `push::push_gate_lock_key`), shared by
the SHARED and EXCLUSIVE sides. The shared push-gate wait is observed
through `observe_advisory_lock(LockType::PushGate, …)`.
- On failure it rolls back the savepoint, logs a warning, and increments
`buzz_db_channel_ttl_refresh_failures_total{reason}`, where `reason` is
`lock_timeout` or `error`. The event still commits, matching the
trigger's `EXCEPTION WHEN OTHERS`. A cancelled statement (`57014`) still
rejects the transaction, because plpgsql never caught that either.
- While both producers run, an app refresh that hits `lock_timeout` is
counted, and then the trigger retries it inside COMMIT and may succeed.
So during the dual window the failure counter can over-report and the
worst-case wait doubles. Both go away when the retirement PR drops the
triggers, after which the counter is exact.

### Call sites

Every production `INSERT INTO events` calls
`event_follow_up::after_admitted_insert`:

- `insert_event_on`
- `insert_event_with_thread_metadata_tx`
- `LockedMemberSnapshot::replace_member_event`
- `replace_addressable_event`
- `publish_nip43_membership_locked`
- `accept_lease_event` (kind 30350, a no-op today, kept so the policy
has no exceptions)

`replace_parameterized_event_in_transaction_impl` inserts inside the
`parameterized_replace` savepoint. It enqueues the push job inside the
savepoint, so a rollback to that savepoint also drops the job, and
records the TTL channel only after the savepoint is released.

The two rolled-back verification probes (`verify_floor_guard_behavior`,
`verify_channel_roster_fence_behavior`) are named exceptions, because
they never commit.

### Source policy

`tests/observability_source.rs` adds
`every_production_event_insert_runs_the_follow_up_hook`. It scans every
`crates/*/src` and fails on any function that inserts into `events`
without the hook. Matching is normalized (letter case, whitespace, `\`
continuations, `\n`/`\t`/`\r` escapes, optional `public.`). The file is
masked once first: comments (`//`, nested `/* */`) and string,
raw-string (including `br"`/`cr"`), and char literals become spaces.
`#[cfg(test)]` markers, `fn` signatures and the hook are all found in
that masked view, so a marker in a comment (even a multiline block
comment) strips nothing, an `fn` line inside a multiline string doesn't
split a function, and a commented-out or quoted hook doesn't count. SQL
is still matched in the original text. A table test pins the masker's
output for each literal form. A fixture test pins what the scan rejects
(no hook, push without TTL, a hook in a line comment, block comment, or
string, lowercase or line-broken or escaped SQL, writers after test-only
items or under comment mentions) and what it ignores (writers in
`#[cfg(test)] mod`). A floor of seven hooked writers catches a scan that
silently stops seeing writers.

### Tests

`src/store/event_follow_up_postgres_tests.rs` is the contract suite from
the BUZZ-176 discovery work, ported to the `AdmittedTx` API. It is a
crate-internal `#[cfg(test)]` module because it runs `SET LOCAL`
timeouts and in-transaction reads through the crate-private
`AdmittedTx::conn()`. It runs on both the desired and migration schemas,
in two arms:

- **dual**: production during the migration window, with the triggers
and the app code both running.
- **app-only**: drops both triggers in the disposable database (and
asserts no partition clones remain), the way the retirement migration
will.

The trigger-only baseline is the base branch, where the same suite
passed before this change. The suite also pins the two branches that
differ from "swallow everything": a `lock_timeout` failure increments
`buzz_db_channel_ttl_refresh_failures_total{reason="lock_timeout"}`
exactly once, and a statement cancel (`57014`) during the refresh
rejects the event with no row, job, or deadline change.

## What got simpler

Nothing yet. This adds a parallel producer during the migration window.
It is what lets the follow-up PR delete two plpgsql functions, two
triggers, and the "keep in sync with migrations/00xx" duplication
between `schema/functions/` and `push.rs`.

## Verification

Rebased onto `main` @ `745501962`. All runs used a Linux cloud
workstation with the pinned toolchain (rustc/clippy 1.95.0, hermit), and
the tree was clean before and after each run. The final head,
`c5a06a82`, changes only `crates/buzz-db/tests/observability_source.rs`
compared with `1eb11bde` (via `fbc9a598`, `7c0baa41`, `9199992c` and
`d405b2f6`). Production source is identical between the two.

| Check | SHA | Result |
|---|---|---|
| `cargo fmt --check`, `cargo clippy -p buzz-db --all-targets -D
warnings` | `fbc9a598` | pass |
| `cargo clippy` (workspace) | `1eb11bde` | pass |
| source policy (`--test observability_source`), fmt, buzz-db clippy |
`c5a06a82` | 17/17, pass, pass |
| `cargo test --locked -p buzz-db` (non-PG) | `c5a06a82` | 148 lib + 17
policy + 5 doctests |
| source policy (`--test observability_source`) | `fbc9a598` | 16/16 |
| `cargo test --locked -p buzz-db` (non-PG) | `fbc9a598` | 148 lib + 16
policy + 5 doctests |
| contract suite (`store::event_follow_up_postgres_tests`,
desired/migration × dual/app-only) | `1eb11bde` | 4/4 |
| buzz-db PG full | `1eb11bde` | 464/464 |
| buzz-relay PG | `1eb11bde` | 378/378 |
| GitHub CI | `fbc9a598` | 53 pass, 0 fail (Codex security review
pending) |

**Falsifications** (each mutation made the named test fail, then was
reverted):
- dropping the `relay_members` hook → policy names
`publish_nip43_membership_locked`
- no-op push producer → app-only arms fail, dual arms pass (trigger
covers)
- skipping the TTL refresh → app-only fails on the deadline; dual fails
on the failure-metric assertion
- swallowing `57014` → all four arms fail
- dropping the metric increment → all four arms fail
- unanchored `#[cfg(test)]` match, or no escape handling → fixture test
fails
- a `#[cfg(test)]` constructor that skips admission, added inside `impl
AdmittedTx` (indented or as a column-0 `mod`) →
`admitted_tx_is_constructed_only_by_admitting_constructors` fails;
putting the strip back into the constructor scan → its fixture test
fails
- at `7c0baa41`: `accept_lease_event`'s hook commented out and the real
call made through an alias → policy names `accept_lease_event` (the same
mutation passes under the `fbc9a598` policy); hook matching on unmasked
text → the comment/string fixtures fail
- at `9199992c`/`d405b2f6`: no nested block-comment depth, no
string-escape skip, no `br"`/`cr"` raw-literal prefix, or no raw-string
branch at all in the masker → the follow-up fixture test fails
- at `c5a06a82`: finding `#[cfg(test)]` in the unmasked text →
`writer_after_block_commented_cfg_test` is no longer reported; finding
`fn` signatures in the unmasked text → `writer_after_raw_string_example`
is no longer reported; no `cr` raw prefix → the masker table test fails
on `cr"`
- unhooked writers appended to `side_effects.rs` (after test-only items,
under a doc-comment mention, with an escaped newline) → policy names
each

**Live relay E2E**: an independent reviewer ran this at `1eb11bde`
against a real relay and CLI, with PostgreSQL 17 and Redis 7, the
follow-up triggers absent, and no partition clones.
- A kind 9 on a TTL channel advanced the shortened deadline by about 580
s. On a permanent channel, the deadline stayed NULL.
- Each accepted event produced exactly one pending `push_match_queue`
row with the same event id.
- An exact signed replay was a no-op.
- While the exclusive TTL lock was held, the event and its job stayed
invisible and the deadline didn't change. After release, both persisted
once.
- Roster create/join/add/remove kept SQL and wire state in step
(1→2→3→2), with one current 39002 head.
- NIP-33 replace, duplicate, stale, failure and retry cases all passed.

Limits: the push lease was a SQL fixture, and push consumers were
disabled. Kind 30023 is global, so channel-scoped TTL on the
parameterized path is covered only by the PG contracts. No live relay
rerun was done at `fbc9a598`, because that delta is test-only.

**Latency** (measured at pre-rebase `f8380927`, same production delta;
debug build on loopback, 1,000 samples per cell, EVENT→OK): head
app-only p50/p99 3.80/4.58 ms (permanent) and 3.87/4.64 ms (TTL),
against base trigger-only 3.49–3.53/4.00–4.03 ms and 3.56–3.62/4.30–4.46
ms. About +0.3 ms p50, from the extra client round trips (lock, UPDATE,
savepoints, push lock/insert) that the triggers ran server-side. One
debug loopback run, not a production p99.

Not measured: contention from many writers on one hot TTL channel, where
each writer now waits on the channel row lock for about two more client
round trips (RELEASE SAVEPOINT and COMMIT) than with the trigger. In
review, a burst of 8 concurrent posts to one TTL channel committed with
no deadlock or lock timeout. Watch send p99 and `pg_locks` waits on
`channels` during rollout.

**Known pre-existing, not touched here:**
`api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo` is
flaky when Redis is present. It returns a 504 in 4 of 5 runs at base
`745501962` and 2 of 5 at `fbc9a598`, always at the same assertion. No
CI lane selects it.

---------

Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>
Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>
2026-10-09 12:33:31 -04:00
..