Make relay readiness process-local by TheSentinel454 · Pull Request #7341 · block/buzz

TheSentinel454 · 2026-09-04T19:20:19Z

Summary

Make Kubernetes readiness depend only on the relay process lifecycle, so a shared Postgres or Redis slowdown cannot withdraw every pod at once.

Move dependency checks to one fixed-cadence loop per pod. The loop permits only one evaluation at a time, emits metrics after each sample, and caches a timestamped report. /_status reads that cache without calling Postgres, Redis, or the deletion catalog. It reports not_yet_sampled, fresh, or stale. Each completed sample also writes a Unix timestamp gauge, so Datadog can compute sample age at query time.

Fail closed when the community lifecycle lookup errors. An inconclusive tenant-state lookup no longer admits a socket to AUTH or REQ handling.

Related issue

None found. This addresses the elevated relay HTTP 500 and reconnect incident investigated on 2026-09-03.

Tradeoff

The readiness gauge now reports the latest private-probe observation, not the shutdown transition itself. After shutdown starts, a scrape can still see 1 until the next readiness probe refreshes the gauge to 0. Kubernetes routing is unaffected because it uses the readiness response from the authoritative process state.

A terminal 0 was never guaranteed: even a transition-owned gauge could update in process and then exit before Prometheus scraped it. If no scrape occurs before exit, both designs miss the terminal sample. The new design adds at most the interval until the next readiness probe when a scrape occurs during shutdown.

Dependency status is now sampled every 30 seconds rather than on demand. A slow evaluation delays the next sample instead of stacking more work. The status payload exposes the cached report age. The completion timestamp stays unchanged when sampling stops, so time() - timestamp crosses the stale threshold without a server aging loop. Outcome counters and duration histograms remain cumulative and cannot provide no-data detection.

Testing

Gimli exercised exact SHA edff1ec4a5362e132e367bf7449d2b0a68f1e9a9 on an isolated Blox stack. Repeated /_status bursts caused no dependency calls, metrics advanced without status traffic, stale status remained visible, and lifecycle lookup failures admitted no AUTH or REQ handling. Follow-up verification at fdbb394ed598c94cde85ed01cb11e9de0ee8f00d confirmed sampler-owned outcome and duration emission without status traffic and bound the real startup seam. The final timestamp-gauge change is covered by targeted red/green tests and the same boot regression at c0f36e22b527c2fd6a63a548d036d006ffa17171.

Complexity

Readiness remains one process-local sample per probe. Dependency I/O now has one owner and one execution path; request volume cannot increase dependency-check load. One completion timestamp replaces the prior server-side age update path; Datadog computes age without another loop. Community admission also returns to one fail-closed rule for inactive and unknown tenant state.

Generated with Claude Code

github-actions · 2026-09-04T19:21:24Z

🔐 Codex Security Review

Status: review required for the current range.

The current range is ebe99a46e8802b9ff20fdf6a1028ce93bdefaa43...b96aa84dd43df6bea3061c71437a5d015a798d27.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review b96aa84dd43df6bea3061c71437a5d015a798d27 to authorize a new review.
Any previous review applies only to its recorded range.

kalvinnchau

🤖 Process-local readiness is the correct architecture, but the bundled fail-open community admission change creates an archived-history read window. Dependency observability also needs an automatic sampling/freshness owner before rollout. The diagnostic endpoint should be bounded before it becomes the incident-time interface.

wesbillman

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: two P2 findings below. The earlier fail-open admission, missing sampler, and request-driven diagnostic concerns are addressed at this head; process-local readiness, the one-time Redis boot gate, and probe-owned readiness telemetry are preserved.

Validation: source-only review of HEAD 3fbb54d876959e4fa45a56d62f9811e58b8b9007 against BASE 77729abfb692b25a0f4ec4a69add86af2e32c0dd, with independent admission, metrics, and regression-selection lanes. Existing CI run 35653008996 passed on a merge tree identical to HEAD, including all three new real-process boot tests. The new unit witnesses were not executed by the configured lanes. No PR code was executed for this review.

Merge criteria: resolve the completion-gauge retention mismatch and select the new contract regressions in the existing test lanes. Provider-owned alert rules are outside this review.

wpfleger96

🤖 I think the counter→gauge switch in 962bdca closes the OpenMetrics problem from 4099060960. Datadog's v2 gauge transformer forwards sample.value as-is, so the full epoch reaches the provider again. The republish cadence also stays under every supported idle timeout: 5s at the 15s floor, capped at 30s. There's still one blocking gap in how the new retention path is tested, plus a smaller ordering issue.

Blocking: nothing guards the production publisher wiring. scrape_retains_the_completion_timestamp_across_gauge_idle_timeout spawns run_dependency_sample_completion_publisher_for_diagnostics itself (readiness.rs#L1200-L1210). startup_owns_the_dependency_sampler waits for the first sampler-written timestamp and then terminates the process (boot_lifecycle.rs#L816-L820). If someone deletes the publisher spawn in main.rs#L1070-L1083, both tests still pass, and production silently goes back to losing the gauge once the sampler stalls past the idle timeout. That's the exact failure this delta exists to prevent.

The fix I'd suggest is to move the "start sampler + start publisher" pair behind one function that main calls. Then add a test for that seam: stop only the sampler, keep publishing, and assert the scrape still returns the same full epoch after a short idle timeout. It needs to fail when the publisher start is removed. A boot test with a small BUZZ_USAGE_METRICS_IDLE_TIMEOUT_SECS would also work, but it's slower.

Minor: a stale republish can move the epoch backwards. The sampler and the publisher both call gauge set, but nothing orders those writes (readiness.rs#L519-L538). On the multi-threaded runtime this interleaving can happen:

The publisher loads A.
The sampler stores B and publishes it.
The publisher then publishes A.

The exported timestamp goes backwards until the next publish. It's bounded to one republish interval, so it's unlikely to trip a 60s staleness monitor, but it can hand a scrape an inflated age. You could hold a small mutex across the load+set and the store+set, or have the publisher only ever re-set the value it reads while holding that lock. The current-thread retention test can't exercise this, so a targeted test would be nice if you touch it.

Also, the Datadog model in datadog_openmetrics_v2_completion_epoch is handwritten. It pins the local metric type, which is useful, but it isn't the real integration, so the doc comment probably shouldn't imply more than that. Head CI was still running when I looked.

wesbillman

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: one P2 ordering defect in the completion-gauge repair, detailed inline. The prior unit-selector omission is fixed; raw gauge semantics and independent idle-retention publication are now present. Process-local readiness, cached status, the initial Redis boot gate, and fail-closed admission remain intact.

Merge criterion: serialize completion advancement and republishing, with a deterministic regression that prevents an old republish from overwriting a newer completion. No provider-alert policy change is requested.

Validation: source-only follow-up from 3fbb54d876959e4fa45a56d62f9811e58b8b9007 to HEAD 962bdca29e268d0d1de5a6560b2cd0806c3c37dd, against BASE 77729abfb692b25a0f4ec4a69add86af2e32c0dd, with independent production and coverage lanes. Completed CI run36071969683 passed; its unit job ran 121 relay tests including the new witnesses on synthetic merge 21d09871bfbe54d7b2ca7cef5599eaea70fd0df2, not the raw pinned head. No PR code was executed for this review.

Remaining validation limits: the retention unit test exercises the real publisher/exporter but bypasses main’s publisher spawn, which is present in source; Datadog transformation is modeled, not integration-tested. These are disclosed gaps, not additional demonstrated production failures.

wpfleger96

🤖 I think ed3d7ae fixes the race from my last review. The production wiring gap I flagged as blocking is still open, though, so I'm keeping this at changes requested.

Race: fixed. The verify-then-retry loop in republish_dependency_sample_completion holds up against the recorder you actually ship. With the locked metrics 0.24.6 / metrics-util 0.20.4 / metrics-exporter-prometheus 0.18.3, gauge set is a swap(.., AcqRel) on the generational AtomicU64, not a plain store. If a stale republish of A overwrites the sampler's B, that swap synchronizes with the sampler's release. The sampler stores the epoch before it publishes, so the republisher's next load has to see B, and the loop re-emits it. It only goes around again when the epoch actually changed, so it can't spin on a stable value, and it never blocks the sampler. The parked-recorder test also discriminates. Swapping the loop back to the 962bdca29 single publish makes it fail on exactly the intended assertion (1700000000 instead of 1700000030), and it passes at this head.

Blocking: production publisher startup is still unguarded. main.rs and boot_lifecycle.rs haven't changed since 962bdca29. We deleted only the completion-publisher spawn at main.rs#L1070-L1084 and ran the tests at this head. Every readiness unit test (13/13) and every boot lifecycle test still passed: 9/9 without infra and 3/3 against Postgres, including startup_owns_the_dependency_sampler. That boot test proves the sampler writes the first timestamp, which it does on its own. scrape_retains_the_completion_timestamp_across_gauge_idle_timeout spawns the private publisher helper itself (readiness.rs#L1203-L1239), and the new race test calls the republish method directly. So if someone later drops that spawn, CI stays green, and production goes back to losing the gauge exactly when sampling stalls. That's the case this whole delta exists for.

The small fix I'd still suggest: put "start sampler + start publisher" behind one function that main calls, then point the retention test at that function. The test should stop only the sampler, idle past the gauge timeout, and assert the scrape still returns the same epoch, and it has to go red when the publisher start is removed. If you'd rather do it as a real boot test, note that the idle timeout is floored at three usage-poller intervals. Setting only BUZZ_USAGE_METRICS_IDLE_TIMEOUT_SECS=15 won't get under the default 900s floor, so you'd also need BUZZ_USAGE_METRICS_INTERVAL_SECS=5.

Minor: the README now overstates the guarantee. deploy/charts/buzz/README.md#L190-L192 says the exported value never regresses. The loop repairs a stale overwrite after it lands, so a scrape that hits the window between writing A and re-writing B can still read A, and preemption can stretch that window. The code comment gets this right ("instead of leaving the exported series moved backwards"). I'd narrow the README to match: a racing republish fixes its own stale write before it returns, rather than leaving it until the next tick.

The one failure in our full buzz-relay run was api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo (504), which matches the environment baseline you described and has nothing to do with this delta. Head CI was still running when I looked.

wesbillman

Carl, an automated reviewer, commenting via Wes’s GitHub account.

No blocking code findings in this follow-up. The previous P2 ordering defect is addressed: the republisher rechecks after its write and repairs a raced completion before returning, rather than leaving the older epoch until the next tick. I accept this verify/retry approach instead of requiring lock serialization. The deterministic parked-recorder regression calls the production methods and would catch the previous single-write implementation.

Process-local readiness, cached status, the initial Redis boot gate, and fail-closed admission remain intact. One nonblocking documentation clarification is inline.

Validation: source-only review of HEAD ed3d7ae7bffb6b86395eb2c825da925991ae9a3b against BASE 77729abfb692b25a0f4ec4a69add86af2e32c0dd, focused on the delta from 962bdca29e268d0d1de5a6560b2cd0806c3c37dd, with independent source and CI-metadata lanes. No PR code was executed. At the 14:35 UTC snapshot, relevant unit and relay integration CI was unfinished; run 36147376862 checks synthetic merge 5c5e439099c21c624b32d306e481966473ac6d83, not the raw head. This is not a green-CI or merge-readiness claim.

Unchanged validation limits remain: production publisher startup wiring is present but not bound by a dedicated integration regression, and Datadog transformation is modeled rather than integration-tested. Their previous nonblocking disposition stands; this review does not resolve other reviewers’ outstanding requests.

TheSentinel454 · 2026-09-25T14:52:37Z

Gimli E2E verdict — exercised and works

Exact head: ed3d7ae7bffb6b86395eb2c825da925991ae9a3b
Environment: isolated Blox validation worktree; fresh named Compose Postgres/Redis; release relays on isolated loopback ports; official datadog-checks-base 38.3.2 OpenMetricsBaseCheckV2 configured with the production fields including send_monotonic_counter: true.

I exercised the relay → /metrics → official OpenMetrics submission boundary and observed:

Before a completion, the raw and transformed metric were absent; repeated /_status calls did not create either.
First completion submitted a full epoch gauge (1790347307 / 1790347307.0), not a counter delta.
A deterministic parked republish plus newer sampler-completion sequence was monotonic at both boundaries: raw and official submission values were [1790347352, 1790347392, 1790347392].
After >15s forced exporter idle retention, raw and transformed epochs remained unchanged.
With only the sampler stopped, six scrapes across 28 seconds retained an identical raw/official epoch; canonical dependency-attempt counter lines were byte-identical across all six scrapes.
/_status remained cache-only.
Two relay processes sharing the isolated Postgres/Redis held independent readiness counters (A 3, B 1).

The deterministic concurrency arm was local to the detached validation worktree and restored byte-for-byte before the clean release-binary probes; final worktree was clean at the tested SHA. I tore down the named Compose project and owned tmux sessions.

Artifact — live raw Prometheus gauge, official submitted gauge point, and recorded race sequence:

Detailed receipts: /home/bloxer/buzz-pr7341-ed3d7ae7/.scratch/pr7341-live-ed3d7ae7/REPORT.md.

wesbillman

Carl, an automated reviewer, commenting via Wes’s GitHub account.

No blocking findings in this follow-up. At HEAD 3de2266efed39930bf74e0c831d8cfbcfc3d4ccb (BASE 77729abfb692b25a0f4ec4a69add86af2e32c0dd), the one-commit delta from ed3d7ae7 narrows the startup-coverage gap and addresses the README clarification:

Main and the retention regression now call the same sampler/publisher startup function. The test waits for a completed sample, cancels only the sampler, and checks that the independent publisher retains the same full epoch beyond the gauge idle timeout. The existing boot witness covers starting the sampler from main; the shared-seam regression now covers keeping its publisher wired alongside it.
The README correctly permits a briefly stale scrape while the existing verify/retry path repairs a raced write before returning. The prior ordering repair and process-local readiness, cached diagnostics, initial Redis boot gate, and fail-closed admission contracts remain intact.

Validation: source-only review, with independent source and CI-metadata lanes; no PR code or mutation tests executed. At the captured CI snapshot, Rust unit coverage was still running and relay/Postgres integration had not reported. Run36157462166 tests synthetic merge d7e7d634e3a1bfc0dcc2bdb1ccdd13877af7451d (main 930b8bb… + this HEAD), not the pinned base/head pair. This is not a green-CI or merge-readiness claim. Datadog transformation remains modeled, not integration-tested; its nonblocking disposition is unchanged. This comment does not dismiss standing change requests from other reviews.

wpfleger96

🤖 Re-review at 3de2266e (base 77729abf). Both findings from my earlier review are fixed and I found no new blockers. Two small non-blocking notes are below.

The startup-wiring blocker is fixed. main.rs now starts both tasks through start_dependency_sampler_and_completion_publisher, and the retention test starts them through that same function. We checked the fix by deliberately breaking the code at each point and confirming that a test fails:

Change we made	Result
Clean head	readiness 13/13, boot lifecycle 12/12 (9 ordinary + 3 Postgres)
Remove only the publisher `tokio::spawn` inside the seam	caught: `dependency_runtime_retains_the_completion_timestamp_when_only_sampler_stops` gets `None` after idle timeout
Remove only the seam call in `main.rs`	caught: Postgres `startup_owns_the_dependency_sampler` never sees the completion metric
Return `Some(0)` before the first write	caught only by the Postgres boot test (`boot_lifecycle.rs:827`, 4/4 runs); every unit test passes
Head restored	everything passes again

The README note is fixed. The text no longer says "never regresses". It now says one scrape can briefly see the older epoch and that the republish repairs it before returning, which matches how the code behaves.

Non-blocking:

Duplicate entry points. run_dependency_sample_completion_publisher has no callers now, and run_dependency_sampler is only called by the router test. The new seam copies their argument handling instead of calling them, and the doc comment on DependencyDiagnostics still says run_dependency_sampler is the only caller of sample. I think having the seam spawn the two existing pub runners, and deleting whichever one ends up unused, would leave a single path and keep the comment accurate.
The "no gauge before the first completion" rule has no direct test. The last row of the table is only caught because the Postgres boot test happens to scrape at the right moment; no unit test covers it. The assertion that used to cover this in the old retention test never actually worked, so nothing was lost, but a direct test would help. One way: hold the evaluator behind a barrier, start through the seam, let a few publisher ticks run, assert the raw series is absent, then release the barrier.

One unrelated note: the full buzz-relay package run has one failure, api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo (504 instead of 200). It also fails on the earlier head ed3d7ae7, so it isn't caused by this PR.

TheSentinel454 · 2026-09-25T18:02:20Z

Addressed the two nonblocking follow-ups at exact head 4ed6d780ee99a96346bc471fee69e00822d37b7b:

The combined startup seam now delegates to the existing sampler and completion-publisher runners, removing the duplicate AppState-to-loop wiring while preserving cadence and cancellation behavior.
I extended the existing production-seam retention regression rather than adding another test. It now blocks the first evaluation across three deterministic publisher ticks, proves the raw completion series remains absent, then releases the sample and continues the existing sampler-stop/idle-retention assertions.

The zero-before-completion mutation fails this regression with Some(0) versus None. On the final code, readiness is 13/13, fmt/clippy pass, and just test-unit completed with one unrelated timing miss in buzz-agent whose exact rerun passed. The full relay package retains the established environment failures: six media Sqlx(PoolTimedOut) cases and the mesh-demo 504.

All inline review threads are currently resolved; there was no new inline thread to resolve for these review-body notes.

This comment was generated by an AI coding agent.

wesbillman

Carl, an automated reviewer, commenting via Wes’s GitHub account.

No blocking findings in this follow-up. HEAD 4ed6d780ee99a96346bc471fee69e00822d37b7b, BASE 77729abfb692b25a0f4ec4a69add86af2e32c0dd; reviewed the one-file delta from 3de2266efed39930bf74e0c831d8cfbcfc3d4ccb and its production callers.

The shared startup seam now uses the existing sampler and publisher runners, preserving their separate cancellation tokens and cadence. The extended retention regression holds the first evaluation across publisher ticks, asserts the completion series is absent, then releases sampling and verifies the independent publisher retains that epoch after sampler cancellation and exporter idle timeout. Both previous nonblocking follow-ups are addressed. One optional test-failure diagnostic improvement is inline. The accepted brief stale-scrape window and other previously reviewed contracts are unchanged.

Validation: pinned-source review on Blox, independently checked against existing hosted CI evidence; no PR code or mutation tests executed for this review. Run 36170855372 passed the 122 selected relay unit tests, including the extended retention regression, and 483 PostgreSQL tests, including the real startup witness. Those jobs tested synthetic merge 7779ad704ba4447c29847c4f200e21153c0b1078 (main 9263cda8 + this head), not the raw pinned head/base pair.

At the captured CI snapshot, Desktop Core remained in progress and Codex Security Review was skipped. No fresh live Datadog validation was performed. This is a clear code review, not approval or a claim that every merge gate is complete.

wpfleger96

🤖 Re-review at 4ed6d780. Both of the non-blocking notes from my last pass are addressed, and I don't see anything blocking.

The duplicate entry points are gone. start_dependency_sampler_and_completion_publisher now spawns the public run_dependency_sampler and run_dependency_sample_completion_publisher, so production (main.rs) and router.rs go through the same runners. The wiring is the same as before: DEPENDENCY_SAMPLE_INTERVAL, the same diagnostics handle and the same two cancel tokens. The updated DependencyDiagnostics doc comment matches what the code does now.

The missing "no gauge before first completion" test is covered too. DelayedEvaluator plus the start_paused runtime holds the first evaluate() open across three republish intervals and asserts the scrape is None. Then it releases and checks that the value shows up and is still there after the idle timeout. A publisher that emitted Some(0) or any placeholder before the first completion would fail this test.

One nit, not blocking: release is only notified once, so after the first sample the sampler's next evaluate() parks on release.notified() forever. It never sees dependency_sampler_cancel. The test still models "sampler stopped" correctly, since no more completions happen, but the cancel isn't really what stops it. If you want cancel to be the thing under test, you could use notify_waiters or a flag so later evaluations return right away.

All CI is green except Desktop Domain / Desktop Core, which was still running when I posted. This PR doesn't touch desktop/.

wpfleger96

🤖 Re-review at 91e5f962. Nothing blocking.

Since my last review at 4ed6d780, the branch was rebased onto main b65cff31 and gained one commit. I compared the PR's own patch before and after the rebase. The only content difference is the Justfile PostgreSQL-lane selector: it now starts from main's #7900 version, which already dropped the two admin test exclusions, and adds the same readiness::tests/router::tests/state::tests selectors as before.

The new commit wraps the sampler-start wait in a 5-second tokio::time::timeout, so a sampler that never starts fails loudly instead of hanging the job. That's safe under the paused clock. The spawned sampler is runnable immediately, its interval's first tick fires at once, and DelayedEvaluator notifies before any await. So auto-advance can't fire the timeout before a working sampler signals.

The nit from my last review still applies and is optional. release is only notified once, so the sampler's second evaluate() parks forever rather than exiting on dependency_sampler_cancel. The test still models "sampler stopped" correctly.

CI at this head: Rust unit ran readiness::tests::dependency_runtime_retains_the_completion_timestamp_when_only_sampler_stops and it passed, along with the rest of readiness::tests. PostgreSQL (484/484), relay E2E and integration are green. Desktop Smoke E2E (4) fails in scroll-history, project-conversation-load-failure and thread-head-stale-edit specs, which this PR doesn't touch. Desktop Core was still running when I posted.

wesbillman

Carl, an automated reviewer, commenting via Wes’s GitHub account.

No blocking findings in this follow-up. HEAD 91e5f9622bcadf3368a9ccbe66c899d1b51d7227, BASE b65cff31a4c5f4a0af63952b60a21fd73195321a; reviewed the rebase and test-only delta from the previous clear head.

The new five-second Tokio timeout bounds the retention test’s sampler-start wait without changing production behavior or weakening its assertions. The immediately runnable sampler and retained Notify permit preserve the paused-clock handshake. The Justfile rebase resolution retains the readiness/router/admission selectors and adopts the base’s corrected admin PostgreSQL classification. Other feature patches are unchanged after accounting for base movement.
Existing CI run 36181632514 tested synthetic merge ca96aab of this exact head/base pair. Unit Tests passed 121/121 selected relay tests, including the changed retention witness and ordering/admission regressions. PostgreSQL Tests passed 484/484, including the real startup witness and relocated admin case.
Remaining gate: overall CI failed because Desktop Smoke E2E (4) failed; this review did not establish its cause or rerun it. The separate Codex security review was skipped. Source-only on the pinned Blox, no reviewer-run code or fresh live Datadog validation. The accepted brief stale-scrape window and previously disclosed limits remain unchanged. This is a clear code review, not approval or a green-CI/merge-readiness claim.

A reconnect burst exhausted the per-pod writer pools and two feedback loops turned that into a total outage. Readiness evaluated shared Postgres, Redis, and deletion-catalog health, so every replica went NotReady together and the burst had nowhere to land. The probe was also part of the load: the deletion-catalog check acquires the writer pool, so each pod spent writer connections against the exhausted pool every five seconds while failing. /_readiness now answers from local process lifecycle only — shutting_down is 503, anything else is 200 — and the dependency evaluation moves to /_status on the same private health listener, under a `dependencies` object carrying the fields the readiness body used to return. No startup state is added: the health listener binds only after the database, migrations, Redis, and pub/sub are up, so a process that can answer has booted. run_registered_community_connection collapsed Ok(false) and Err into "not active", so a writer-pool timeout in is_community_active read as confirmed archival and dropped the socket, which reconnected and re-checked. Only a confirmed Ok(false) cancels now; a lookup failure admits the socket with a structured warning and defers to the periodic revalidate_live_communities backstop. Writes are unaffected and remain fail-closed on their own per-event fence. Telemetry keeps its existing names: buzz_readiness_checks_total narrows to {ready, shutting_down}, the dependency families are now sampled by /_status, dependency gauges are dropped, and one new bounded counter, buzz_community_admission_checks_total{outcome}, counts the admission decision. The per-pod raw-series ceiling drops from 99 to 86. This deletes the readiness publication machinery — the mutex, probe generations, ProbeTicket/ProbeStart, finish_probe, finish_public_evaluation, and a second shutdown flag duplicating AppState::shutting_down. All of it existed to order concurrent async dependency evaluations against shutdown. Readiness is now a single atomic load, so the one ordering guarantee still worth keeping — a racing shutdown must win, and never leave a draining pod advertising a ready gauge — is a post-write re-read in record_readiness_probe rather than a generation-fenced mutex. Co-authored-by: Claude Code <[email protected]> Redis had no startup gate at all. `deadpool_redis` pools dial lazily and PubSubManager::new only allocates channels, so "Redis pub/sub connected" was logged against a dead port and boot ran to completion. With readiness now answering from local lifecycle alone, such a pod bound its health listener and advertised ready for the rest of its life. state:: verify_redis_command_path acquires one connection from the command pool and issues PING before AppState is built, and therefore before the health listener binds, because binding is the one-way latch that makes a pod routable. No startup_ready flag is added for the same reason. Post-start Redis failures are unchanged: they are dependency failures and never move readiness. Postgres startup connection behavior is untouched. Signed-off-by: tornquist <[email protected]>

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]> Signed-off-by: tornquist <[email protected]>

Co-authored-by: Codex <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Signed-off-by: tornquist <[email protected]>

Socket admission treated a failed `is_community_active` lookup as grounds to admit, deferring eviction to the periodic revalidator. That begins serving AUTH and REQ frames for a tenant whose lifecycle is unknown, which `docs/multi-tenant-relay.md` I5 (`Inv_AdmissionFence`) does not permit: read and membership capability belong only to an actor currently admitted to that community. The adjacent host-binding seam already refuses on exactly this evidence. Both non-affirmative outcomes now cancel before any frame is read. The `buzz_community_admission_checks_total{outcome}` counter still separates `inactive` from `check_error`, so an operator can tell archival from database pressure without the admission decision depending on that distinction. Co-Authored-By: Claude Opus 5 <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Signed-off-by: tornquist <[email protected]>

`/_status` evaluated Postgres, Redis, and the deletion catalog on every request. That made the load a pressured dependency sees a function of how often someone looked at the endpoint, with nothing bounding how many evaluations could be in flight, and it left the dependency metrics flat whenever nobody was looking — during exactly the outage they exist to explain. `DependencyDiagnostics` now owns one fixed-cadence loop (`run_dependency_sampler`, 30s) that is the sole caller of the evaluator. It awaits each evaluation before taking the next tick, so a pod never holds more than one open; a dependency slower than the cadence lowers the sampling rate instead of stacking probes on the slowness that caused it. Each cycle republishes the existing dependency counters and histograms and caches the report with its observation time. `/_status` now only reads that cache and performs no dependency I/O, so it can be polled freely. Its `dependencies` object always carries a `sample` field — `not_yet_sampled`, `fresh`, or `stale` — plus the report's age, so a cached verdict can never be mistaken for a current one. Freshness is also observable from a scrape alone via a new `buzz_readiness_dependency_sample_age_seconds` gauge, following the existing `buzz_storage_sweep_age_seconds` convention: absent until the first report exists, so absence means "not yet sampled" rather than "fresh". The per-pod series ceiling moves from 86 to 87. `/_readiness` is untouched: still process-local lifecycle, still one sample per probe, same response and telemetry contract. Co-Authored-By: Claude Opus 5 <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Signed-off-by: tornquist <[email protected]>

Freshness does not need a series of its own. The dependency outcome and duration families stop receiving samples the moment the per-pod sampler stops, and the Datadog monitors alert on that no-data gap — so an age gauge would only add a series that the very loop whose absence it is meant to report has to keep advancing. A wedged sampler would freeze it at its last value and read as permanently fresh. Per-report freshness stays where a human reads it: `/_status` keeps its `sample`, `sample_age_seconds`, and `sample_interval_seconds` fields and still distinguishes not-yet-sampled from fresh from stale. The sampler cadence, single in-flight evaluation, and cached-read `/_status` are unchanged. Drops the readiness series ceiling from 87 to 86. Co-Authored-By: Claude Opus 5 <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Signed-off-by: tornquist <[email protected]>

…cleanup Signed-off-by: tornquist <[email protected]> Co-authored-by: Amp <[email protected]> Signed-off-by: tornquist <[email protected]>

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]>

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]> Signed-off-by: tornquist <[email protected]>

The completion-epoch gauge has two writers: the dependency sampler, which owns the epoch, and the idle-refresh publisher, which may only re-emit it. The publisher read the stored epoch and wrote it as two separate steps, so a sample completing in between left the older epoch as the last write — the exported series moved backwards for up to one publisher interval, which is exactly the window freshness alerting reads. The metrics facade offers a bare `set` with no compare-and-set, so the ordering has to come from the writers. Serializing them under one lock would put the sampler's authoritative write behind an idle refresh; instead the republisher now verifies after its write that the epoch it wrote is still the stored one, and re-emits the newer one if a completion landed while that write was in flight. Another pass costs another completed sample, so it ends as soon as nothing is racing it. The regression parks a republish inside the recorder — the last point of its write, after it has read the epoch — completes a newer sample behind it, then releases it and asserts the scrape still reports the newer completion. Against the unfixed publisher it reports the older epoch. Co-Authored-By: Claude Opus 5 <[email protected]> Signed-off-by: tornquist <[email protected]>

Signed-off-by: tornquist <[email protected]> Co-authored-by: Amp <[email protected]> Signed-off-by: tornquist <[email protected]>

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]> Signed-off-by: tornquist <[email protected]>

Rereview

wesbillman

Carl, an automated reviewer, commenting via Wes’s GitHub account.

No blocking source findings in this rebase follow-up. HEAD b96aa84dd43df6bea3061c71437a5d015a798d27, BASE ebe99a46e8802b9ff20fdf6a1028ce93bdefaa43; compared against the previously cleared head.

The production feature patches are unchanged. The Justfile conflict resolution preserves the newer base’s library/binary and NIP-FI selectors while adding the readiness and admission regressions. Rechecked the new base’s ingress/listener integration: private probes remain independent of NIP-FI, the public readiness route stays exempt, and sampler/publisher startup and shutdown ownership remain intact. Previously accepted completion-gauge race and modeled Datadog validation limits are unchanged.

Validation gate remains: source-only review, no reviewer-run code. Existing CI run 36437990913 has a successful Rust Lint result, but unit and PostgreSQL/relay test lanes were unfinished or not yet reported at the captured snapshot. Synthetic merge 72c47c1f83e9a0089b79458500d4d41c08327005 has the same tree as this head. Prior-head test passes do not establish current-head passes. This is a clear source review, not approval or merge-readiness certification; passing required CI remains a merge prerequisite.

wpfleger96

🤖 Re-review at b96aa84d (base ebe99a46). Nothing blocking.

Since my last review at 91e5f962, this is a rebase from main b65cff31 onto ebe99a46 with no new commits. I merged the old head onto the new base and diffed that against this head. The only differences are the two conflict resolutions. Both keep both sides:

Justfile test-unit: main's NIP-FI selector (--bin buzz-relay, nip_fi_*, router::tests::, parse_query_tests, off_mode_precedence_tests, and the kind(bin) clause) plus this PR's readiness::tests:: and the state::tests::neither_a_confirmed_inactive_community_nor_a_failed_lookup_admits_the_socket selector. router::tests:: shows up once.
router.rs imports: main's nip_fi_http::http_denial plus this PR's DependencySnapshot.

I also checked how the new main commits in these files interact with the PR. #7264 exempts /_readiness on the public router and leaves build_health_router alone. Its JWKS warm and refresh don't feed readiness, so readiness stays process-local as intended. #7793 adds operator-listener workers to main.rs, but nothing there touches readiness or community admission. start_dependency_sampler_and_completion_publisher still runs in the same place in startup.

The optional nit from my earlier review still applies: DelayedEvaluator's second evaluate() parks instead of exiting on cancel.

CI at this head: Rust unit ran all 13 readiness::tests, 24 router::tests, and the fail-closed state::tests case, and they passed. PostgreSQL passed 555/555, including boot_lifecycle::postgres_tests::startup_owns_the_dependency_sampler and both Redis boot-timeout tests. Relay E2E, backend integration and Desktop E2E Relay are green. Desktop Core, Smoke E2E (1/2/4) and Desktop E2E Integration were still running when I posted. This PR doesn't touch desktop files.

* origin/main: Make relay readiness process-local (#7341) Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> # Conflicts: # Justfile # scripts/run-tests.sh

Resolve conflicts with #7341 (relay readiness process-local): - Justfile / run-tests.sh: keep both sides' selectors. - router.rs: take main's readiness helpers, using Config::for_test(). - state.rs: keep the cancellation select! and on_not_run drain around main's fail-closed admission match and metrics. Co-authored-by: Will Pfleger <[email protected]> Signed-off-by: Will Pfleger <[email protected]>

…in-ui * origin/main: test(desktop): wait for channel head refresh before paging thread summary test (#7955) 🤖 perf: bound long-thread aux reads and make query deadlines terminal (#7854) Add native HPKE encryption for nsec backups (#7849) test(desktop): scope video menu e2e probes to emitted messages (#7953) Add owner deletion admission control plane (#7818) fix(sidebar): converge stale-at-open state across devices (sections/sort/stars/mutes) (#7805) feat(nip-fi): harden Blossom kind-24242 verifier to NIP-FI spec (#7288) Make relay readiness process-local (#7341) 🤖 docs(nip-fi): remove implementation references from the spec (#7912) Signed-off-by: Sol <49aa1f65411fd096d2e2ec144f1e7aa36fdc76d1b907cfdf7be000c66f9d3b8e@buzz.block.builderlab.xyz>

## Why The partition manager checks partition existence by name only and treats Postgres 42P17 "would overlap partition" errors as success. On databases where a catch-all partition (`events_p_future` / `delivery_log_p_future`) covers future months, the monthly creation path silently does nothing while real coverage erodes toward a write outage. There is currently no visibility into partition catalog health and no signal before writes start failing. ## What - **Read-only catalog audit** in `buzz-db` (`partition.rs`): classifies the live partition catalog for `events` and `delivery_log` via `pg_inherits` and bound parsing — coverage bounds, catch-all detection, anomalous children, and trigger parity checked recursively down to routable leaf partitions. - **Creation gated on the audit verdict**: the 42P17-to-success swallow is removed; monthly CREATE runs only for months the audit proves uncovered, a canonical-name mismatch is an error, and per-month outcome capture replaces first-error abort. New `BUZZ_PARTITION_MANAGER_CREATE_ENABLED` kill switch (default `true`). - **Prometheus metrics** per table: `buzz_partition_serving_safe`, `buzz_partition_uncovered_months` (audit window is now through +3 months), `buzz_partition_catch_all_covered_months`, `buzz_partition_anomalous_children`, `buzz_partition_trigger_parity_missing`/`_extra`, `buzz_partition_audit_duration_seconds`, `buzz_partition_audit_runs_total{outcome}`, `buzz_partition_audit_failures_total`, `buzz_partition_create_attempts_total`, and `buzz_partition_audit_last_success_timestamp_seconds` for staleness alerting. - **Cached diagnostics**: `/_status.partition_catalog` reports partition serving-safety, audit age, and freshness. `/_readiness` stays process-local, consistent with #7341; missing, unsafe, or stale audits do not remove pods from service. - **Periodic audit task** in the relay, plus config surface for the audit interval and the monthly-create kill switch. Catch-alls are detected from catalog bounds rather than configured names. - Doc correction: the mesh heartbeat comment no longer claims readiness gating (it never was gated; behavior unchanged). ## Behavior changes & risk - No DETACH/DROP/ATTACH and no schema migrations. The only DDL is the pre-existing monthly CREATE path, now strictly narrower (audit-proven-uncovered months only) and behind a kill switch. - Partition audit health does not gate readiness. Until the first completed audit, read-only retries back off from 5 seconds to a 60-second cap. Any completed audit, including unsafe coverage, restores the normal interval. - Partition-overlap errors now surface as errors instead of being swallowed as success. - Rollback: revert the commit, or set `BUZZ_PARTITION_MANAGER_CREATE_ENABLED=false` to disable the creation path while keeping the audit and metrics. ## Validation - New Postgres-backed regression tests for catalog classification and trigger parity (disabled child trigger, `ENABLE ALWAYS` parent, disabled nested leaf clone in a multi-level layout, healthy-catalog zero-parity checks). Each new regression was verified to fail against the previous logic before the fix. - Local affected-target validation passed against a disposable current-schema database, with the known mesh forwarded-echo and tracing callsite failures excluded. This is not a claim that the full suite passes. Follow-up work (separate PRs): bounded catch-all advance (empty-only golden path; non-empty reattach only behind an explicit operator flag, default off), fresh-install convergence, and proactive coverage-runway alerting. --- ## Update — 2026-08-21 - Fixed nested-leaf trigger parity auditing so child-only row triggers are checked on every routable descendant leaf and reported as `{leaf}:{trigger}` under the owning root child. - Added a Postgres regression test for a child-only trigger on a nested leaf; mutation-reverting to immediate-child-only extra-trigger scanning makes it fail. Generated with Codex Signed-off-by: coder 0 <d97ebdbb198c7237c94f84ea8bb8a73583ea067407eebd0062abbb3962527fb1@buzz.block.builderlab.xyz> Signed-off-by: Ian Oberst <[email protected]> Signed-off-by: Ian Oberst <[email protected]> Co-authored-by: coder 0 <d97ebdbb198c7237c94f84ea8bb8a73583ea067407eebd0062abbb3962527fb1@buzz.block.builderlab.xyz> Co-authored-by: Codex <[email protected]> Co-authored-by: Claude Opus 5.5 <[email protected]>

## Summary Make Kubernetes readiness depend only on the relay process lifecycle, so a shared Postgres or Redis slowdown cannot withdraw every pod at once. Move dependency checks to one fixed-cadence loop per pod. The loop permits only one evaluation at a time, emits metrics after each sample, and caches a timestamped report. `/_status` reads that cache without calling Postgres, Redis, or the deletion catalog. It reports `not_yet_sampled`, `fresh`, or `stale`. Each completed sample also writes a Unix timestamp gauge, so Datadog can compute sample age at query time. Fail closed when the community lifecycle lookup errors. An inconclusive tenant-state lookup no longer admits a socket to AUTH or REQ handling. ### Related issue None found. This addresses the elevated relay HTTP 500 and reconnect incident investigated on 2026-09-03. ### Tradeoff The readiness gauge now reports the latest private-probe observation, not the shutdown transition itself. After shutdown starts, a scrape can still see `1` until the next readiness probe refreshes the gauge to `0`. Kubernetes routing is unaffected because it uses the readiness response from the authoritative process state. A terminal `0` was never guaranteed: even a transition-owned gauge could update in process and then exit before Prometheus scraped it. If no scrape occurs before exit, both designs miss the terminal sample. The new design adds at most the interval until the next readiness probe when a scrape occurs during shutdown. Dependency status is now sampled every 30 seconds rather than on demand. A slow evaluation delays the next sample instead of stacking more work. The status payload exposes the cached report age. The completion timestamp stays unchanged when sampling stops, so `time() - timestamp` crosses the stale threshold without a server aging loop. Outcome counters and duration histograms remain cumulative and cannot provide no-data detection. ### Testing Gimli exercised exact SHA `edff1ec4a5362e132e367bf7449d2b0a68f1e9a9` on an isolated Blox stack. Repeated `/_status` bursts caused no dependency calls, metrics advanced without status traffic, stale status remained visible, and lifecycle lookup failures admitted no AUTH or REQ handling. Follow-up verification at `fdbb394ed598c94cde85ed01cb11e9de0ee8f00d` confirmed sampler-owned outcome and duration emission without status traffic and bound the real startup seam. The final timestamp-gauge change is covered by targeted red/green tests and the same boot regression at `c0f36e22b527c2fd6a63a548d036d006ffa17171`. ### Complexity Readiness remains one process-local sample per probe. Dependency I/O now has one owner and one execution path; request volume cannot increase dependency-check load. One completion timestamp replaces the prior server-side age update path; Datadog computes age without another loop. Community admission also returns to one fail-closed rule for inactive and unknown tenant state. Generated with [Claude Code](https://claude.ai/code) --------- Signed-off-by: tornquist <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Codex <[email protected]> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5 <[email protected]> Co-authored-by: Amp <[email protected]>

## Why The partition manager checks partition existence by name only and treats Postgres 42P17 "would overlap partition" errors as success. On databases where a catch-all partition (`events_p_future` / `delivery_log_p_future`) covers future months, the monthly creation path silently does nothing while real coverage erodes toward a write outage. There is currently no visibility into partition catalog health and no signal before writes start failing. ## What - **Read-only catalog audit** in `buzz-db` (`partition.rs`): classifies the live partition catalog for `events` and `delivery_log` via `pg_inherits` and bound parsing — coverage bounds, catch-all detection, anomalous children, and trigger parity checked recursively down to routable leaf partitions. - **Creation gated on the audit verdict**: the 42P17-to-success swallow is removed; monthly CREATE runs only for months the audit proves uncovered, a canonical-name mismatch is an error, and per-month outcome capture replaces first-error abort. New `BUZZ_PARTITION_MANAGER_CREATE_ENABLED` kill switch (default `true`). - **Prometheus metrics** per table: `buzz_partition_serving_safe`, `buzz_partition_uncovered_months` (audit window is now through +3 months), `buzz_partition_catch_all_covered_months`, `buzz_partition_anomalous_children`, `buzz_partition_trigger_parity_missing`/`_extra`, `buzz_partition_audit_duration_seconds`, `buzz_partition_audit_runs_total{outcome}`, `buzz_partition_audit_failures_total`, `buzz_partition_create_attempts_total`, and `buzz_partition_audit_last_success_timestamp_seconds` for staleness alerting. - **Cached diagnostics**: `/_status.partition_catalog` reports partition serving-safety, audit age, and freshness. `/_readiness` stays process-local, consistent with block#7341; missing, unsafe, or stale audits do not remove pods from service. - **Periodic audit task** in the relay, plus config surface for the audit interval and the monthly-create kill switch. Catch-alls are detected from catalog bounds rather than configured names. - Doc correction: the mesh heartbeat comment no longer claims readiness gating (it never was gated; behavior unchanged). ## Behavior changes & risk - No DETACH/DROP/ATTACH and no schema migrations. The only DDL is the pre-existing monthly CREATE path, now strictly narrower (audit-proven-uncovered months only) and behind a kill switch. - Partition audit health does not gate readiness. Until the first completed audit, read-only retries back off from 5 seconds to a 60-second cap. Any completed audit, including unsafe coverage, restores the normal interval. - Partition-overlap errors now surface as errors instead of being swallowed as success. - Rollback: revert the commit, or set `BUZZ_PARTITION_MANAGER_CREATE_ENABLED=false` to disable the creation path while keeping the audit and metrics. ## Validation - New Postgres-backed regression tests for catalog classification and trigger parity (disabled child trigger, `ENABLE ALWAYS` parent, disabled nested leaf clone in a multi-level layout, healthy-catalog zero-parity checks). Each new regression was verified to fail against the previous logic before the fix. - Local affected-target validation passed against a disposable current-schema database, with the known mesh forwarded-echo and tracing callsite failures excluded. This is not a claim that the full suite passes. Follow-up work (separate PRs): bounded catch-all advance (empty-only golden path; non-empty reattach only behind an explicit operator flag, default off), fresh-install convergence, and proactive coverage-runway alerting. --- ## Update — 2026-08-21 - Fixed nested-leaf trigger parity auditing so child-only row triggers are checked on every routable descendant leaf and reported as `{leaf}:{trigger}` under the owning root child. - Added a Postgres regression test for a child-only trigger on a nested leaf; mutation-reverting to immediate-child-only extra-trigger scanning makes it fail. Generated with Codex Signed-off-by: coder 0 <d97ebdbb198c7237c94f84ea8bb8a73583ea067407eebd0062abbb3962527fb1@buzz.block.builderlab.xyz> Signed-off-by: Ian Oberst <[email protected]> Signed-off-by: Ian Oberst <[email protected]> Co-authored-by: coder 0 <d97ebdbb198c7237c94f84ea8bb8a73583ea067407eebd0062abbb3962527fb1@buzz.block.builderlab.xyz> Co-authored-by: Codex <[email protected]> Co-authored-by: Claude Opus 5.5 <[email protected]>

* feat(push): support configurable HTTP(S) delivery URLs (#7877) The relay can use a configurable HTTP(S) gateway delivery URL and signs the same URL it sends. The gateway verifies NIP-98 against the received request URL, including authority, port, path and query. App Attest, scoped grants, replay checks and delivery quotas are unchanged. Forwarding proxies must preserve Host and supply the original request scheme through X-Forwarded-Proto. The NIP relay-delivery wording now defines the configured HTTP(S) URL as the signed URL and labels the public URL as an example.  --------- Signed-off-by: Tom Brow <[email protected]> * docs(protocol): propose simplified channel artifacts (#7791) ## Summary Adds a short, proposal-only **NIP-AR: Channel Artifacts** in `docs/nips/NIP-AR.md`, as a simpler alternative to the closed #7771. - Defines complete-snapshot artifact events with stable identity and atomic, `prev`-based revisions. - Uses channel access and posting permissions for reads, edits, moves, and writer-authorized deletion. - Keeps client-defined content opaque to the relay, with exact tag filtering over current accessible state and bounded queries. - Covers durable source removal on moves, terminal deletion, and safe client fallbacks without defining task/project schemas or changing application behavior. ### Remaining design work This is a compact draft, not a complete implementation-ready wire contract. Concrete query request/pagination/error/limit-discovery formats, removal/replay wire details, and numeric query limits remain follow-up work. Prefer extending shared WebSocket `REQ` / HTTP `/query` surfaces rather than adding plugin-specific endpoints. No database layout or scale guarantees are proposed. ### Related issue Closest prior proposal: #7771 (closed). Searched existing PRs and issues for channel artifacts; no matching issue found. ### Testing - Verified the committed document is byte-for-byte identical to the reviewed local draft. - Parsed the example JSON and its embedded JSON content; checked unique two-element example tags. - Reviewed the entire one-file diff and ran `git diff --check`. - Commit and push hooks passed (including DCO sign-off and differential file-size checks). - Full application CI was not run locally: this changes only a Markdown proposal, with no implementation or UI changes. --------- Signed-off-by: Fizz <400e8babadcee6a7f420103f10a2849d84c4a9c71d5bd04f3948c814216648a3@buzz.block.builderlab.xyz> Signed-off-by: Smartie <fb3185faacfc3760b6b4fe0085a8878d8dd537f7a7671c7d3184fe1aa1b04df4@buzz.block.builderlab.xyz> Signed-off-by: Honey <8e307ae0076a4dab6b94b036ea3edc7e08f823a625269c1e6919e881a048b4d2@buzz.block.builderlab.xyz> Co-authored-by: Fizz <400e8babadcee6a7f420103f10a2849d84c4a9c71d5bd04f3948c814216648a3@buzz.block.builderlab.xyz> Co-authored-by: Honey <8e307ae0076a4dab6b94b036ea3edc7e08f823a625269c1e6919e881a048b4d2@buzz.block.builderlab.xyz> Co-authored-by: Smartie <fb3185faacfc3760b6b4fe0085a8878d8dd537f7a7671c7d3184fe1aa1b04df4@buzz.block.builderlab.xyz> * feat(relay): deliver pubkey mentions to relay companions (#7793) We are introducing a companion service to the relay that needs pubkey event mentions for pubkeys it manages. This PR introduces an outbox for pubkey mentions that will be sent to these "operator listener" services. ## Summary Deliver mentions of registered pubkeys to deployment-global operator listeners. - Configure listeners with `BUZZ_OPERATOR_LISTENERS`; listeners manage target pubkeys through NIP-98-authenticated `POST`/`DELETE /operator/listener/pubkeys` requests. - During supported event ingestion, match `p` tags to registrations and insert one outbox row per listener in the event transaction. - A background worker claims up to 10 rows, sends NIP-98-signed notifications, and retries transient failures with exponential backoff for up to 9 attempts (idle polling backs off from 250 ms to 2 s). - Outbox rows are ineligible for delivery after 15 minutes and are reaped every 5 minutes. Registered pubkeys live for 30 days; re-registering renews them, and a daily reaper removes expired registrations. - Keep persistence app-managed: no database triggers, functions, foreign keys, or separate match queue. ## Changed behavior Listener outbox rows are enqueued inside the shared event-insert and thread-metadata transactions; enqueue failure rolls back the event. `event_mentions` behavior is unchanged: ordinary event/reaction mention indexing remains post-commit best effort with warning-only failures. ## Testing - `cargo fmt --all` - `cargo test -p buzz-db --lib` - `cargo test -p buzz-relay --lib config::tests::operator_listener_routes` - `cargo check -p buzz-db -p buzz-relay` * fix(db): limit event transactions to listener mention kinds (#7932) ## Summary - Keep non-listener-mention event writes on the plain insert path without opening a transaction. - Preserve the transaction around listener mention event insertion and outbox enqueue. ## Validation - `cargo fmt --all -- --check` (Hermit) - Tests not run. Follow-up to Baxen’s review of #7793, point 1. Signed-off-by: Implementor <691cca7a870db1dad6990d5938d1b4a2a2ca9647ca81290b536c17b06b2e473f@buzz.block.builderlab.xyz> Co-authored-by: Implementor <691cca7a870db1dad6990d5938d1b4a2a2ca9647ca81290b536c17b06b2e473f@buzz.block.builderlab.xyz> * fix(relay): fail startup on invalid operator listener config (#7933) Addresses point 3 of [previous comment](https://github.com/block/buzz/pull/7793#pullrequestreview-5333444423) "3. Fail fast on a bad BUZZ_OPERATOR_LISTENERS (config.rs:857)" ## Summary - Propagate malformed `BUZZ_OPERATOR_LISTENERS` values from `Config::from_env` as `ConfigError`, including invalid UTF-8. - Update startup config tests to assert returned errors and restore the original admin warning capture helper, removing the shared helper introduced only for listener log assertions. - Cover valid and absent listener values through `Config::from_env`. ## Context Follow-up to the review of #7793 specifically [reverting some config logging parts](https://github.com/block/buzz/pull/7793/changes#diff-eaa0eeb209ff1ad6212ffa56d3a983bb732858647c9fb227ef7483a3363b5a71). Invalid listener configuration currently logs an error and silently disables listener delivery. ## Verification - `cargo fmt --all -- --check` passed with Hermit. Signed-off-by: Implementor <691cca7a870db1dad6990d5938d1b4a2a2ca9647ca81290b536c17b06b2e473f@buzz.block.builderlab.xyz> Co-authored-by: Implementor <691cca7a870db1dad6990d5938d1b4a2a2ca9647ca81290b536c17b06b2e473f@buzz.block.builderlab.xyz> * 🤖 docs(nip-fi): remove implementation references from the spec (#7912) This removes implementation references and implementation status from `docs/nips/NIP-FI.md` so the spec holds normative text only. It drops the Blossom compliance note, the known-gap notes, crate/file paths and PR numbers, roadmap "supersedes" sentences, doc-history lines, and the design-rationale note on session-only vs deny-until-TTL (its restart re-push SHOULD remains stated normatively elsewhere). Two wording changes carry normative weight: `PUT /media/upload` is listed as a plain kind-24242 upload route instead of a temporary alias, and the JWKS fetcher's SSRF controls become a MUST instead of a description. It doesn't depend on any enforcement PR and can merge at any time. Related: #7265 --------- Signed-off-by: Will Pfleger <[email protected]> Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz> * Make relay readiness process-local (#7341) ## Summary Make Kubernetes readiness depend only on the relay process lifecycle, so a shared Postgres or Redis slowdown cannot withdraw every pod at once. Move dependency checks to one fixed-cadence loop per pod. The loop permits only one evaluation at a time, emits metrics after each sample, and caches a timestamped report. `/_status` reads that cache without calling Postgres, Redis, or the deletion catalog. It reports `not_yet_sampled`, `fresh`, or `stale`. Each completed sample also writes a Unix timestamp gauge, so Datadog can compute sample age at query time. Fail closed when the community lifecycle lookup errors. An inconclusive tenant-state lookup no longer admits a socket to AUTH or REQ handling. ### Related issue None found. This addresses the elevated relay HTTP 500 and reconnect incident investigated on 2026-09-03. ### Tradeoff The readiness gauge now reports the latest private-probe observation, not the shutdown transition itself. After shutdown starts, a scrape can still see `1` until the next readiness probe refreshes the gauge to `0`. Kubernetes routing is unaffected because it uses the readiness response from the authoritative process state. A terminal `0` was never guaranteed: even a transition-owned gauge could update in process and then exit before Prometheus scraped it. If no scrape occurs before exit, both designs miss the terminal sample. The new design adds at most the interval until the next readiness probe when a scrape occurs during shutdown. Dependency status is now sampled every 30 seconds rather than on demand. A slow evaluation delays the next sample instead of stacking more work. The status payload exposes the cached report age. The completion timestamp stays unchanged when sampling stops, so `time() - timestamp` crosses the stale threshold without a server aging loop. Outcome counters and duration histograms remain cumulative and cannot provide no-data detection. ### Testing Gimli exercised exact SHA `edff1ec4a5362e132e367bf7449d2b0a68f1e9a9` on an isolated Blox stack. Repeated `/_status` bursts caused no dependency calls, metrics advanced without status traffic, stale status remained visible, and lifecycle lookup failures admitted no AUTH or REQ handling. Follow-up verification at `fdbb394ed598c94cde85ed01cb11e9de0ee8f00d` confirmed sampler-owned outcome and duration emission without status traffic and bound the real startup seam. The final timestamp-gauge change is covered by targeted red/green tests and the same boot regression at `c0f36e22b527c2fd6a63a548d036d006ffa17171`. ### Complexity Readiness remains one process-local sample per probe. Dependency I/O now has one owner and one execution path; request volume cannot increase dependency-check load. One completion timestamp replaces the prior server-side age update path; Datadog computes age without another loop. Community admission also returns to one fail-closed rule for inactive and unknown tenant state. Generated with [Claude Code](https://claude.ai/code) --------- Signed-off-by: tornquist <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Codex <[email protected]> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5 <[email protected]> Co-authored-by: Amp <[email protected]> * feat(nip-fi): harden Blossom kind-24242 verifier to NIP-FI spec (#7288) Brings `buzz-media`, `buzz-relay`, all first-party kind-24242 minters, and desktop token minting into compliance with [NIP-FI §kind-24242](https://github.com/block/buzz/blob/main/docs/nips/NIP-FI.md). ## What changed **`buzz-media/src/auth.rs`** - Add `BlossomStrictness` enum (`Strict` | `Permissive`). `Strict` applies full NIP-FI rules (active modes); `Permissive` preserves pre-NIP-FI Off-mode behavior byte-identical [FI-INV-15]. - Rewrite `verify_blossom_auth_event_for_verb` with count-based cardinality: exactly one `t`/`expiration`/`server` in `Strict`; duplicate `x` also rejected. `Permissive` keeps main's boolean semantics exactly: any valued `t` other than the verb (including `""`) rejects, valueless `t` is ignored. - `Strict`: mandatory `server` tag on all proofs (upload + read); absent or mismatched → `evidence_rejected` (`ServerMismatch`). - `Strict`: 60-second proof window (`now - created_at <= 60s`, `expiration <= created_at + 60s`). `Permissive`: 3600s / optional server. - **[F1]** Permissive server validation uses any-match semantics: a proof with multiple `server` tags is accepted if any tag matches the bound host. This restores origin/main base behavior. Strict duplicate-rejection unchanged. - **[F1 compat]** Permissive server gate uses `server_values.is_empty()` (valued tags only) rather than `server_count > 0` (includes valueless tags). A lone valueless `["server"]` tag is treated as absent in Permissive/Off mode, matching pre-NIP-FI base behavior [FI-INV-15]. - **[F4]** Valueless `x` tags in Strict get reads are tracked before `filter_map` so they cannot become absent scope (host-wide authorization). Any `x` tag present in Strict must contain the exact requested sha256. - **[F3 unit]** Cases A–D in `auth.rs` are helper-level unit tests: they call `verify_blossom_upload_auth` and `verify_upload_hash_only` directly. They do not enter the upload pipeline (`process_upload`/`process_video_upload`). Retained as helper evidence. **`buzz-media/src/error.rs`** - Add `DuplicateTag(&'static str)` variant. - Add `blossom_denial_kind()` method: classifies each auth error as `MissingEvidence`, `EvidenceRejected`, or `AuthorizationDenied`. Non-auth errors return `None`. - `IntoResponse` retains the legacy JSON 401 shape [FI-INV-15]. **`buzz-relay/src/api/media.rs`** - Add `MediaDenial(MediaError, BlossomStrictness)` wrapper mapping to byte-exact NIP-FI fixed responses in `Strict`; falls through to legacy JSON in `Permissive`. - `blossom_strictness_from_state()` selects `Strict` when `state.config.nip_fi.is_enforce()`, otherwise `Permissive`. Strictness is threaded through the `admit_nip_fi_http_on_state` NIP-98 closures on upload and read, and through the post-admission X-SHA-256, hash-binding, and membership denials. - `extract_blossom_auth` keeps first-value `Authorization` extraction; Enforce rejects repeated fields at the `admit_nip_fi_http` cardinality gate, and Off keeps legacy behavior [FI-INV-15]. - Both membership-denial call sites use `media_denial(RelayMembershipRequired, strictness)` so Strict mode produces the correct fixed-text response. - `upload_blob` serving-write fence conversion (`:406`) uses `map_err(|e| media_denial(e, strictness))` — a community fence committed between auth admission and lease acquisition no longer resets Strict to Permissive. - Mode-driven regressions in `mod postgres_tests` (selected by the nextest `postgres-ci` profile via `test(/postgres_tests::/)`, `#[ignore = "requires Postgres"]`), run through the full relay router with a real Enforce verifier and assertion: Enforce rejects Permissive-only proofs (300s lifetime, missing `server` tag) on both upload routes and reads with `evidence rejected`; Off accepts the same proofs with pre-NIP-FI responses; DenyProtected answers 503 before any proof check; membership denials are `authorization denied` text/plain in Enforce and exact legacy JSON 403 in Off, with a member positive control. GET and HEAD are each discriminated (HEAD with a suppressed body). Both upload routes pin the handler's `X-SHA-256` missing/malformed/unsigned and post-body hash-mismatch denials in both modes. Off rejects an empty-valued `t` beside a valid one with legacy 401 JSON in either order, and ignores a valueless one. Exact status, Content-Type, challenge, and body bytes are pinned. **`buzz-media/src/upload.rs`** (`mod minio_tests`) - **[F3 pipeline]** Four tests exercising the actual post-body call sites (`process_upload` `:85`, `process_video_upload` `:413`) with real MinIO I/O: buffered/streaming × expired-proof-accept + mismatched-hash-reject. The positive cases use `fresh_strict_upload_auth` (`created_at = now-58`, `expiration = now+2`, lifetime = 60s) — Strict-admissible at sign time — followed by a real 3s sleep so the proof is expired when the upload completes. `nostr::Timestamp::now()` reads the OS wall clock directly; paused Tokio time does not advance it. The negative cases use a pre-expired proof with a mismatched `x` tag. All four are `#[ignore = "requires MinIO"]`; no CI lane runs them automatically. **`buzz-media/src/validation.rs`** - `minimal_valid_mp4()` promoted to `#[cfg(test)] pub(crate)` — a 618-byte pre-computed H.264/avc1 fast-start MP4 available to all `buzz-media` test modules; smoke-tested by `test_minimal_valid_mp4_passes_validate_video_file`. **`desktop/src-tauri/src/commands/media.rs`** - `sign_blossom_upload_auth`: `server` tag mandatory; upload expiry 60s (was 3600s/300s). - `MEDIA_GET_AUTH_EXPIRY_SECS`: 60s (was 600s). **`desktop/src-tauri/src/media_proxy.rs`** - Single re-mint+retry on 401/403 for range requests; non-auth failures do not retry. **`crates/buzz-cli/src/client.rs`** - Read expiry: 60s (was 600s). Upload expiry: 60s. `server` tag mandatory on upload. **`crates/buzz-dev-mcp/src/view_image.rs`** - `MEDIA_GET_AUTH_EXPIRY_SECS`: 60s (was 600s). Test updated. **`mobile/lib/shared/relay/media_auth.dart`** - `_mediaGetAuthLifetimeSeconds`: 60 (was 600). Refresh margin updated. **`mobile/lib/shared/relay/media_upload.dart`** - `_uploadAuthLifetimeSeconds`: 60 (was 300). `server` tag mandatory. **`mobile/lib/features/channels/media_viewer_page/video_viewer.dart`** - **[F2]** Remove Android-specific `VideoPlayerController.networkUrl` streaming path. `video_player_android` 2.9.5 freezes headers into static `DefaultHttpDataSource` request properties — a 60s proof minted at controller creation time becomes stale on seeks. All platforms use the authenticated local-file download path. - **[F2 transport]** `unawaited(request.sink.close())` before `client.send()`. `AbortableStreamedRequest` carries no request body; without closing the sink, `IOClient.send()` awaits `stream.pipe(ioRequest)` which blocks until the sink ends — every video download hung in loading indefinitely on every platform. - **[F2 pending-ctrl]** `pendingController` ref set before the first `await (initialize())`, cleared in all exit paths. Effect cleanup disposes `pendingController.value` so a close-during-init releases the native player even if the initialized event never arrives. - **[F2r(a)]** On native init failure (post-create, pre-initialized-event), the inner catch starts disposal detached via `unawaited(localController.dispose().catchError(...))` — the `.catchError` handler absorbs any disposal exception so it does not reach the test error zone — then rethrows the original load error. `video_player` 2.11.1 completes the init future with an error without disposing the native player. - **[F2r(b)]** Non-2xx error body cancelled via `_cancelVideoResponse()` (subscribe+cancel) instead of `drain()`. `drain()` waits for the upstream to close; a stalled server body blocked `initializeVideo` indefinitely. - **[F2r(d)]** `unawaited(localController.dispose().catchError(...))` in the catch — not `await`. Two failure mechanisms exist: (1) when `createWithOptions()` throws, `_creatingCompleter` is never completed and `await dispose()` deadlocks at `:682-683`, blocking the outer catch from setting error state. (2) when `createWithOptions()` succeeds but initialization fails, `dispose()` runs but its thrown exception becomes an unhandled async error reaching the test zone. Both are fixed: `unawaited` lets the outer catch run immediately and set `error.value`; `.catchError(...)` on the detached disposal future absorbs any disposal exception. **`mobile/test/features/channels/media_viewer_page/video_viewer_test.dart`** - `_FinalizingFakeClient`: calls `request.finalize().drain()` — a test without the sink fix times out because the drain never completes, validating the transport contract. - F2r(a): `forceInitError=true` fake emits `PlatformException` on subscribe; `disposeCallCount >= 1` verifies disposal even on init failure. - F2r(b): `stalledBody` `StreamController` with `onCancel` Completer (bounded completion signal, not a sleep). Asserts: (1) `bodyStreamCancelled=true` while body stream is still open (impossible with `drain()`); (2) error UI visible while body remains open. Restoring `drain()` breaks both. - F2r(c): `neverInitialize=true` fake never sends initialized event; unmount asserts `disposeCallCount >= 1` via `pendingController`. Distinct from the event-error case. - F2r(d): `forceCreateError=true` fake throws `PlatformException` from `createWithOptions()` itself (before any player ID is returned). Asserts error UI visible within a bounded deadline. With the old `await dispose()` the outer catch is blocked — `error.value` is never set and the error UI assertion fails at the deadline; with `unawaited(dispose())` the error text appears immediately. **`mobile/test/features/channels/media_viewer_page/video_viewer_transport_test.dart`** (separate file) - Real-IO loopback probes using `flutter_test` (not `package:test`) to avoid `depend_on_referenced_packages` lint. No `TestWidgetsFlutterBinding` — no HttpClient override interfering with `dart:io`. - Probe 1: `HttpServer.bind(loopbackIPv4, 0)` reads the full request body before replying. Without `sink.close()`, `req.drain()` hangs and the test times out. - Probe 2: server signals request arrival via a Completer (not a sleep); abort fires after confirmed arrival; `client.send()` must throw `RequestAbortedException` (typed assertion) within a bounded 5s deadline. **`scripts/test-video-upload.sh`** - Proof minted with `+60` expiry and mandatory `server` tag. **`buzz-test-client/tests/e2e_media*.rs`** + **`buzz-relay/src/api/media.rs` test fixtures** - All fixtures updated to 55s expiry + `server` tag. **`RELEASING.md`** - New "NIP-FI upload proof freshness (relay floor)" section documenting that 60s proofs require the first relay release carrying this PR's post-body hash-only check (the first tag > `v0.2.1` — update once cut) for reliable large-file uploads. Operators on older self-hosted relays (≤ `v0.2.1`) must upgrade before receiving these clients. ## Finding 3: 60s upload proofs vs old-relay compatibility Desktop/CLI/mobile upload proofs are now 60s. Older relays re-run full expiry verification after the body is transferred. A valid upload whose body transfer takes >60s will fail on an old relay. **Resolution (relay floor prerequisite):** `RELEASING.md` requires that verified supported deployments (relay releases confirmed to carry the post-body hash-only check, commit `75e9bef748`) be in place before distributing 60s-proof client builds. Unknown or unverified self-hosted relay deployments are excluded from distribution until they upgrade. This makes the verified-deployment status a prerequisite for release distribution, not a post-distribution advisory. The concrete tag (`> v0.2.1`) is to be recorded once cut. ## Sequencing note Builds on #7264 (merged): Blossom strictness is derived from its `config.nip_fi` mode in this PR, so enabling `BUZZ_NIP_FI_MODE=enforce` activates the strict verifier with no further wiring. ## GIF compatibility exception An unauthenticated Off-mode request on a configured tenant with no GIF provider changes from 404 to 401 (base `gifs.rs:269-275` checked an unconfigured provider first; the current code authenticates first). All other Off-mode Blossom responses are byte-identical to pre-NIP-FI behavior. --------- Signed-off-by: Will Pfleger <[email protected]> Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> * fix(sidebar): converge stale-at-open state across devices (sections/sort/stars/mutes) (#7805) Adds bounded-backoff recovery reads to all four sidebar sync hooks (sections, sort, stars and mutes). A stale relay read at app open now converges without a user edit or a reconnect. ## What this does **Shared recovery hook (`useStaleReaderRecovery`).** All four hooks use one retry effect. It reads immediately on mount, then at 5, 10, 30 and 60 s, staying at 60 s after that. A change of `visibilityState` to `visible` triggers an immediate read. Reads are single-flight. The effect restarts whenever `pubkey` or `relayUrl` changes, so a hook that stays mounted while switching relays drops the old relay's in-flight reads. **Guards that stop a recovery read from rolling back a local edit:** 1. **Skip the read while an edit is pending.** If an edit is pending when a tick starts, the tick skips its read and just schedules the next one. Without this, the read could return the pre-edit blob after the edit published and pending cleared. At that point neither apply-time guard could reject it. 2. **Pending check inside the state updater.** `hasPending()` and the effect lifetime are re-read inside `setStore(prev => ...)`. That way the check runs when React executes the updater, not when the response arrives. 3. **Local-mutation revision.** Each hook counts its local edits. The count is snapshotted when a read starts and checked again at apply time. If an edit landed while the read was in flight, the response is discarded. 4. **Head advanced only after a successful cache write.** A failed `write*Store()` leaves the same head retryable on the next tick. **Ownership-aware pending clear.** Each sync manager's `doPublish(store)` now clears `pendingStore` only while it still holds that same `store`, on both the identical-payload early return and the success path. Before, an older publish that finished after a newer edit had replaced `pendingStore` wiped the newer edit's pending marker, so a recovery read before the newer debounce could apply the older relay head over it. `destroy()` still clears unconditionally. ## Scope Reader-side recovery plus the ownership-aware pending clear. No outboxes, arbitration or replay changes. It applies to `useChannelSections`, `useChannelSortPreference`, `useChannelStars` and `useChannelMutes`. Related: [#7806](https://github.com/block/buzz/pull/7806) --------- Signed-off-by: Will Pfleger <[email protected]> Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> * Add owner deletion admission control plane (#7818) ## Summary Adds the relay and database admission boundary for owner-requested deletion of archived hosted communities. The operator endpoint records accepted owner intent with stable UUID idempotency and immutable owner/operator provenance. Admission serializes with unarchive and owner transfer, and accepted requests disappear from actionable owner listings. This keeps destructive execution out of the request path. The existing durable deletion engine remains the only executor, so this change adds no lifecycle state or second deletion mechanism. Complexity stays bounded: one durable request is both the idempotency record and the mutation fence. ### Related issue None found. ### Testing - `REDIS_URL=redis://127.0.0.1:6379 BUZZ_POSTGRES_ADMIN_URL=postgres://buzz:buzz_dev@localhost:5432/postgres PGHOST=localhost PGPORT=5432 PGUSER=buzz PGPASSWORD=buzz_dev PG_BIN_DIR=/tmp/buzz-pg-bin ./scripts/postgres-test-run.sh -p buzz-db -p buzz-relay --lib --tests` — 385 passed. - `cargo test -p buzz-db` — passed. - `cargo fmt --all -- --check` and `cargo clippy -p buzz-db -p buzz-relay --all-targets -- -D warnings` — passed. - `just desktop-test desktop-build desktop-tauri-check desktop-tauri-test web-build` — passed; Desktop ran 6,589 tests. - Full `just test` could not start uncached Keycloak dependencies because `quay.io` reset connections. Full `just ci` reached Flutter dependency resolution, then `pub.dev` reset connections. Generated with Codex --------- Signed-off-by: tornquist <[email protected]> Signed-off-by: Codex <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Codex <[email protected]> Co-authored-by: Claude Opus 5 <[email protected]> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> * test(desktop): scope video menu e2e probes to emitted messages (#7953) ## Summary Fixes the `Desktop Smoke E2E (4)` failure on `main`. The test at `desktop/tests/e2e/video-attachment.spec.ts` ("right-click menus expose distinct selectors for links, relay video, and off-relay video") fails 3/3 attempts on main and on every PR branch since ~Sept 25. Because "Desktop" is a required check, that blocks merges. **Cause:** the relay-video and off-relay-video probes picked their player with `getByTestId("video-player").last()`. When mock messages share a second, timeline ordering can put a different video last. The locator then resolves to the wrong player, and the "Download video" menu detaches before the click, so the test times out. **Fix:** scope each probe to the `data-message-id` of the message `emitVideoMessage` just returned. Test-only change, 16 lines. ## Attribution This is a cherry-pick of `dfd5db4e0` by @tornquist, originally part of #7827 (the deletion-drain cron, which is stacked on another feature branch). It's pulled out on its own so main can go green without waiting on that stack. Authorship is preserved. ## Testing - `pnpm build:e2e && playwright test tests/e2e/video-attachment.spec.ts --project=smoke`: 13/13 passed locally, including the target test. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: tornquist <[email protected]> Signed-off-by: murderbot <3754f8729004d95654c46dbab3129e4ab9ef05cc2534e2a3fbfc155983bd637b@buzz.block.builderlab.xyz> Co-authored-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]> * Add native HPKE encryption for nsec backups (#7849) ## Summary Add a Rust API that encrypts an nsec into a backup envelope using RFC 9180 Base mode: DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, and AES-256-GCM. --------- Signed-off-by: jm <[email protected]> Signed-off-by: Jordan Mecom <[email protected]> Co-authored-by: Codex <[email protected]> * 🤖 perf: bound long-thread aux reads and make query deadlines terminal (#7854) Long threads (over ~100 replies) time out in desktop. The aux hop that loads reactions and other e-tag references builds its filter as one `tags @> …` term per id, joined with `OR`. Past about 100 ids the planner switches to walking each partition's primary key backward, expecting to stop early. When few rows actually match, it scans the whole community. With a dirty GIN pending list, a 188-reply thread never finishes. ### What changes - **Set-based e-tag reads (`buzz-db`).** The aux e-tag query now puts the id set behind a `MATERIALIZED` CTE and matches with `ANY`. Each e-tag read also runs under a transaction-local `statement_timeout` of 20 s. - **Terminal timeout contract (`buzz-relay`).** When a read hits the deadline, the client gets a terminal timeout (`CLOSED` for REQ, the timeout error for COUNT and search), not a retryable failure. - **Subscription lifecycle (`buzz-relay`).** The per-connection subscription map lock is now the lifecycle lock. Claims, replacement, client `CLOSE`, owner-checked timeout and search cleanup, revoke, and connection teardown all change the map, the registry, topic refcounts and terminal frames while holding it. As a result, a timed-out subscription's `CLOSED` goes out before any replacement with the same id can claim it, and claims made after teardown are refused. - **Dropped terminal frame disconnects (`buzz-relay`).** If the `CLOSED` for a retired subscription (owner-checked timeout or channel eviction) can't be queued, the relay cancels the connection instead of leaving the client holding a subscription that will never receive fan-out. A client-initiated `CLOSE` ack is exempt. - **COUNT under the same deadline (`buzz-db`).** The fast COUNT path runs e-tag counts under the same transaction-local 20 s cap as SELECT, so WS COUNT and HTTP `/count` produce the terminal timeout too. - **Replica reads surface the deadline (`buzz-db`).** When a replica-routed read is cancelled by `statement_timeout` (SQLSTATE `57014`), the error is returned instead of re-running the query on the writer, which would run the same slow statement. Other replica errors still fall back to the writer. `PLANS/REPLICA_FULL_READ_ROUTING_DESIGN.md` records the exception. - **Deadline handling (desktop).** Only the relay's `query timed out` counts as a query deadline. A client-side `request timed out` stays retryable. For one-shot reads a deadline is terminal: the global query retry (budget 1), thread-replies retry and reaction hydration don't re-send the same slow query. Reaction ids held back by a deadline are released when the channel is opened again, so reopening retries them while same-channel re-renders don't. Live subscriptions, in both the renderer and the native archive-sync socket, keep treating a deadline `CLOSED` as transient: they back off and resubscribe with the same filter instead of being dropped. - **Deadline handling (mobile).** Mobile recognizes the deadline on both transports: HTTP `503 {"error":"query timed out"}` and the WS `CLOSED` reason. - The root `ProviderScope` retry policy returns no retry for deadline errors and keeps Riverpod's default backoff for everything else. - Background thread-summary recounts don't retry a deadline. - Forum posts polling pauses while the last load settled on a deadline; reopening the forum retries. - A channel's newest-window load surfaces a deadline instead of falling back to legacy WS history, and the channel list's batched queries return "unavailable" on a deadline instead of fanning out to per-filter fallbacks. An unavailable batch is not treated as empty. Known last-message timestamps and unread state are kept, and unread catch-up moves `lastMessageAt` forward (never backward) the same way live events do, so a cold start with no known timestamp still gets one. - A live subscription that gets a deadline `CLOSED` backs off and resubscribes with the same filter. History requests still fail on it. - Settled load failures show a Retry control, matching desktop's thread-replies error card: a shared `LoadErrorView` on the channel timeline, forum thread and forum posts list, and an icon button beside the thread replies summary. While the thread query has no value, the thread page shows the route snapshot plus live, cached and optimistic replies, with the loading or error status still visible. - Other re-sends (reconnect, foreground resume, live events, the unread backstop, scroll) are not suppressed; each is bounded by the relay's 20 s statement deadline. - **Long-thread seeder.** `just seed-long-thread [replies]` posts one thread (default 187 replies) with some reactions to the local dev relay, for reproducing long threads in the apps. It uses a throwaway key, refuses non-loopback relays and ignores ambient `BUZZ_*` credentials. Writes are paced to fit the stock relay rate limit. **Lifecycle concurrency.** The lock serializes one connection's subscription changes. Other connections can still be delayed by pressure on the shared pubsub command queue, and by serial eviction loops waiting behind a blocked connection. This PR does not claim strict isolation between connections. **Recovery vs. load.** Clients stop automatic retries of the same one-shot read, but they don't remember deadlines across other triggers: reconnect, resume, live events and the unread backstop can each send the read again later, bounded by the 20 s statement deadline. A live subscription that hits the deadline resubscribes with its original filter under the existing 1–30 s backoff, and against a filter that keeps timing out it retries at the 30 s cap indefinitely, so the worst case is one bounded query per subscription every 30 s. `since` is deliberately not advanced to now on resubscribe, because that would skip events missed while the subscription was closed. Unchanged from `main`: when mobile's channel history sync fails with cached messages available, the cached messages are shown without the error or Retry control. ### Benchmark Local reproduction on an isolated bench stack (not committed): - PG16, migrations applied, one 188-reply thread plus 5M background events in the same community. - Each request replays the desktop thread-replies filter through the relay, with `include_aux` on. Times are total ms for 3 runs, with a 60 s client cap. GIN pending-list state is controlled with `VACUUM` (clean) or by refilling the pending list (dirty), and recorded per partition with `pgstatginindex`. Dirty runs held 402 pending pages on every partition's tags index at the start and end of each matrix. Clean runs held 0–1 pages (relay startup writes). | build | GIN pending state | limit 10 | 50 | 100 | 200 (188 ids) | |---|---|---|---|---|---| | `main` | clean | 26 / 16 / 13 | 56 / 51 / 52 | 92 / 93 / 95 | 662 / 639 / 641 | | `main` | dirty | 315 / 298 / 327 | 22141 / 15888 / 16769 | 28992 / 27819 / 28080 | timeout ×3 (>60 s) | | this PR | clean | 35 / 21 / 14 | 57 / 49 / 48 | 82 / 80 / 75 | 153 / 150 / 135 | | this PR | dirty | 290 / 254 / 251 | 1257 / 1204 / 1206 | 2432 / 2378 / 2382 | 4333 / 4706 / 5104 | Baseline `origin/main` `b37e47721`; this PR at `5f2650f5f`, whose e-tag read builders are identical to the current head. At head `1ad81d868` against `origin/main` `15d44dcce`, limit 200 measured 145–179 ms clean (`main` 683–715) and 4.41–4.51 s dirty (`main` timeout ×3). Every completed cell returns the same signed event set: 209 events, 187 replies at limit 200. With `include_aux` off, every cell is ≤66 ms. The thread-window loader (`select_aux`) is unchanged from `main`, and its timings and captured plans match `main`'s. Actual aux-hop statements captured from each relay binary with `auto_explain` (analyze + buffers), execution ms: | build | clean, 100 ids | clean, 188 ids | dirty, 100 ids | dirty, 188 ids | |---|---|---|---|---| | `main` (N-way `OR`) | 40 | 298 | 28785 | 62892 | | this PR (`MATERIALIZED` fence + `ANY`) | 23 | 45 | 1992 | 3539 | **What the fence changes** - On `main`, the planner combines `ORDER BY created_at … LIMIT` with an overestimated match count and walks each partition's primary key backward, expecting to stop early. With few real matches it scans the whole community: the dirty 188-id statement touches ~4.9M shared buffers on `main` vs ~0.6M with the fence. - The fence prevents that early-stop plan. Across the measured cases (1–188 ids, both pending states), the planner used the GIN tags index. The fence doesn't force GIN in general; a broad enough filter could still get a different plan. **Tradeoff:** the fence materializes every match before sorting. In this bench small limits stayed within run-to-run noise of `main`. A single hot id (5,000 reactions, limit 100) measured 30–34 ms unfenced vs 35 ms fenced. **Deadline:** each e-tag read (SELECT and COUNT) runs under a transaction-local `statement_timeout` of 20 s. It only tightens: a shorter operator timeout (`BUZZ_DB_STATEMENT_TIMEOUT_MS`) is kept. It's a per-statement limit, not a per-request one, so a request that runs several pages or hops can take longer than 20 s in total. The benchmark does not force the deadline. --------- Signed-off-by: Will Pfleger <[email protected]> Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz> * test(desktop): wait for channel head refresh before paging thread summary test (#7955) 🤖 ## Summary Main's Desktop Smoke E2E (4) job fails on `scroll-history.spec.ts` ("thread summary badge survives a retained older-history prepend"). This change fixes the test's timing. It does not change app code. When a channel opens, the app starts a live subscription. When that subscription is ready, the app fetches the newest page again, and that fetch replaces the whole loaded history. This test scrolled up before that refresh happened. On slower CI runners, the refresh came after the older page loaded but before it showed on screen. The older rows went away, the reader stayed at the top, and no more pages loaded. All three attempts failed that way. The test now calls `waitForMockChannelHeadReady` before it scrolls, like the other pagination tests in this file already do. That helper waits for the live subscription and its refresh to finish. ### Related issue Main CI failure at `15d44dcc` (https://github.com/block/buzz/actions/runs/36470599751/job/109092076235). The same failure was reported on #7827. ### Testing - Added temporary logs to see the order of events. Locally, the refresh ran after the older page had loaded: the loaded history went from 2 pages back to 1. The test passed only because it checked before the next render. With the wait, the refresh runs first and nothing replaces the loaded pages later. - `playwright test --project=smoke tests/e2e/scroll-history.spec.ts`: 18 passed. This test with `--repeat-each=8`: 8 passed. ### Follow-up (not in this PR) The app has the same race for real users. If someone scrolls up before the live subscription is ready, or during a reconnect, the refresh can drop the older history they loaded. If they are at the top of the list, paging stops until they scroll down and back up. Signed-off-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> * fix(mobile): stale community selection during mobile invite setup (#7951) Buzz sets up starter channels when a person accepts an invite. If the phone already had a saved community, the first attempt could fail. Retry could then succeed. A delayed read could replace the new active community with the old one. The read now leaves the saved selection unchanged. The fix also delays channel-status updates until the channel provider finishes initialization. ### Before and after Controlled Flutter app captures against local relays, with the same delayed storage read. The before capture restores the pre-fix active-community provider in the test harness. The after capture uses the fixed provider. These are separate from the native iOS validation below. | Before: first attempt fails | After: first attempt succeeds | | --- | --- | | ![Before: starter channel setup error with Retry setup button](https://github.com/user-attachments/assets/14d8ba45-6e53-40ae-bc10-f219f08d2f92) | ![After: joined community with Continue to welcome channel button](https://github.com/user-attachments/assets/7dc32d9d-3aae-4378-913c-8ac68cc7d930) | ### Validation - Regression tests reproduce the delayed-read ordering and passing timing control; removing the channel sequencing safeguards makes their regressions fail. - Production app against local relays passes the forced race on the first attempt. - Native iOS simulator with an existing saved community accepted the original invite using a fresh identity, joined on the first attempt, and opened the welcome channel without Retry. Signed-off-by: Tom Brow <[email protected]> * Schedule the deletion drain safely (#7827) ## Why The deletion engine already exposes a one-shot `buzz-admin deletions drain` command, but operators have no safe way to schedule it. A generic workload wrapper could expose arbitrary commands or inherit relay credentials, which would add a second control plane and widen the blast radius. ## What This PR adds an opt-in Kubernetes CronJob for the typed deletion drain command. It is stacked on #7818, which adds owner-request admission. ## How The chart keeps the job disabled by default. The CronJob uses `Forbid`, zero Kubernetes retries, bounded runtime and history, and only the database, Redis, and object-store settings required by the executor. PostgreSQL leases, checkpoints, and retry timing remain the sole durable retry authority. The closed `_operator-jobs.tpl` helper centralizes safe CronJob mechanics without creating an arbitrary command or environment registry. This leaves the touched system simpler than a general job framework would. ## Risk The deployment blast radius is low because the job is disabled by default. When enabled, it can run destructive deletion work that the database has already approved, so the chart limits concurrency, retries, credentials, and execution time. ## Testing Rendered every `deploy/charts/buzz/ci/*.yaml` fixture with `helm template`; all passed at `e68cb753bb6673aa1baa60046969bdb2d4738b62`. Ran the full independent Desktop, Tauri, and web lanes; all passed at `e68cb753bb6673aa1baa60046969bdb2d4738b62`. Flutter package resolution made no progress within three minutes, so the mobile lane is not claimed green. ## Bigger picture A later stack layer must inventory and approve admitted owner requests. Until then, this scheduler cannot make a new owner request destructive. Generated with Codex --------- Signed-off-by: tornquist <[email protected]> Signed-off-by: Codex <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Codex <[email protected]> Co-authored-by: Claude Opus 5 <[email protected]> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> * fix(desktop): resolve unlisted project channel requests (#7619) ## Summary - resolve project channel-creation approvals through the authoritative home-channel selector - permit owner-visible unlisted project homes when their channel and repository binding match - add regression coverage for the unlisted authoritative-home path ## Validation - `just ci` - focused project-home regression tests (10/10) - full Desktop suite (6,451/6,451) - `pnpm check` - `pnpm build` ## Manual verification After merging into a Desktop build, approve the pending LBX Copywriting workroom request from the Litbox OS project. Signed-off-by: crgallego <[email protected]> Co-authored-by: crgallego <[email protected]> * feat(relay): implement NIP-AR channel artifacts (#7919) ## Summary Implements NIP-AR channel artifacts (spec merged in #7791) on the relay, after a simplicity pass over the earlier two-agent implementation. An artifact is an editable record (kind 45010) with a stable identity (`d`), one home channel (`h`), and full-snapshot revisions chained by `prev`: - **Writes:** one transaction per write. It locks the artifact's head row, requires `prev` to name the current revision, records the revision in a ledger that survives retention, and advances the head. Two competing edits can't both win. A stale edit gets `conflict: artifact head changed`. Resubmitting an accepted event succeeds without applying it twice. - **Permissions:** writes pass the same gates as a kind 9 message in `h`. A move also passes them in the source channel. The move stores the destination snapshot and a relay-signed kind 45011 removal marker for the source in the same transaction, so both channels recover by replay. The marker never names the destination. - **Moderation:** redaction is the ordinary kind 9005 removal. The ledger keeps the ID so `prev` checks still work. Redacting the current revision retires the artifact. - **Reads:** HTTP `/query` and `/count` accept explicit `artifact: current|history` filters with exact multi-character tag matching (e.g. `#assignee`). Generic REQ and search return only current revisions. Kind 5 against artifacts is rejected. NIP-11 advertises the limits. - **Spec:** NIP-AR updated to match: kind 9 permission checks, 9005 redaction and retirement, no creator-only delete rule. A separate small commit routes `insert_channel_head_checked` through the metered writer pool (`acquire_writer`), like every other event write in that module. ### Related issue Follows #7791. No separate issue found. ### Testing - Clippy clean. - Unit lane passes. Failures seen along the way came from agent env leaking into `buzz-acp` tests (they pass in a clean env) and known timing flakes (`keepalive_resets_idle_past_deadline`, two `buzz-agent` databricks tests that passed on retry). This diff doesn't touch those crates. - Postgres lane passes, including new `artifact_postgres_tests` in `buzz-db` and `buzz-relay`. Three presence tests need `REDIS_URL` set. - Docker smoke against a fresh local relay, 29/29: create and idempotent resubmit, update and stale conflict, current, `#assignee` and history queries, generic REQ, kind 5 rejection, delete and restore, move with source marker, private-channel isolation, and 9005 retirement. - A pasteable curl walkthrough of the same flows was shared with the reviewer. Draft until the human hands-on check (AGENTS.md step 3) is confirmed. The pre-push hook was skipped because every lane above had already run on this tree. CI is the gate. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Honey <8e307ae0076a4dab6b94b036ea3edc7e08f823a625269c1e6919e881a048b4d2@buzz.block.builderlab.xyz> Signed-off-by: murderbot <3754f8729004d95654c46dbab3129e4ab9ef05cc2534e2a3fbfc155983bd637b@buzz.block.builderlab.xyz> Co-authored-by: Honey <8e307ae0076a4dab6b94b036ea3edc7e08f823a625269c1e6919e881a048b4d2@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]> Co-authored-by: Smartie <fb3185faacfc3760b6b4fe0085a8878d8dd537f7a7671c7d3184fe1aa1b04df4@buzz.block.builderlab.xyz> Co-authored-by: Fizz <400e8babadcee6a7f420103f10a2849d84c4a9c71d5bd04f3948c814216648a3@buzz.block.builderlab.xyz> Co-authored-by: murderbot <3754f8729004d95654c46dbab3129e4ab9ef05cc2534e2a3fbfc155983bd637b@buzz.block.builderlab.xyz> * Automate owner deletion preparation (#7830) ## Why Owner deletion admission stops at `submitted`. Manual inventory and approval still stand between owner intent and the existing deletion executor, preventing self-serve deletion. ## What The existing `buzz-admin deletions drain` process prepares and automatically approves operator-attested owner requests. Operator-origin requests retain manual approval. ## How The drain prioritizes approved work, then claims one owner submission with the existing generation lease. It freezes inventory and records digest-bound `owner_automatic` approval in one transaction before entering the unchanged executor. Before approval, the transaction rechecks archived state and current ownership. It locks the deletion advisory fence, community, owner memberships, and request in that order. A regression test pins privileged abort during a live preparation lease. What got simpler: one drain still owns preparation and execution. There is no second worker, queue, lifecycle, or retry authority. The rebased branch contains only this feature and its review fixes. ## Risk Automatic approval permits irreversible deletion without a human grace period. Operator attestation is not a cryptographic owner signature. Provenance, locked authority checks, generation fences, and digest-bound approval constrain the operation. This remains work in progress. Broad test failures and incomplete mobile checks are disclosed below; publication is not a merge-ready verdict. ## Testing Published head: `e059ae9056b447ca3b5d0c2893da86550ef16f5c`. All seven commit trees match tested source `5605f27eaece1e809f746cc1839b55c7ceef8d80`; only attribution metadata changed. Source-SHA results below are not new-head execution receipts. At source commit `5605f27eaece1e809f746cc1839b55c7ceef8d80`, isolated PostgreSQL tests showed stale archive and ownership fixtures fail closed after the fix. Before the fix both reached automatic approval. Removing abort's generation increment or stage transition made the new live-lease regression fail; restored production passed. `just test` failed in two ACP native-git fixtures and one agent body-timeout test. The failing source files match the pinned base, but there is no exact-base execution comparison proving those failures unrelated. `just test-unit` also failed in the ACP fixtures, leaving 18 tests unrun. `just ci` stopped in Flutter tooling package resolution; separately run non-mobile lanes do not constitute a full `just ci` pass. No live tenant deletion or human testing was performed. A dedicated populated `0052` → `0053` approval-backfill fixture remains a coverage gap. Final-head hosted CI and security review are required. ## Bigger picture Rebased directly onto main `12670bd0f037c66a682272bb81c46c3f254fad74`; prerequisite #7818/#7827 are already merged. Main owns `0052_channel_artifacts`, so this feature's automatic-approval migration is now `0053`. Client/KGoose and quota work are separate PRs and are not part of this diff. Generated with Codex --------- Signed-off-by: Codex <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Codex <[email protected]> Co-authored-by: Claude Opus 5 <[email protected]> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> * feat(mobile): add the contextual identity-name resolver (#7894) 🤖 ## Summary When two identities share a display name, Buzz mobile shows the same label for both. A reader cannot tell a person from an agent, or one person's agent from another's. For example, a channel can show three agents and one human all named "murderbot". This PR adds the naming rules that fix this, without changing any screen yet. It ports the contextual identity-name contract (v1) from the desktop app to Dart. Given the identities shown together, the resolver gives each public key a distinct label: - A human keeps the plain name. Agents that share it get a qualifier. - The viewer's own agents are named before other people's agents. - An agent is qualified by its owner's name first ("Wes's Honey"). A short public-key suffix is added only if that is still ambiguous ("baxen's murderbot · xa8v"). It also adds two providers that screens will use: - `channelIdentityNamesProvider` compares names against a channel's members, plus any referenced non-member such as an old author or an outside mention. - `watchIdentityNames` compares a set of identities shown together outside a channel, and loads their profiles. The next PRs in this stack connect these to the screens. Part 1 of 3: #7894 (resolver) → #7895 (conversations) → #7896 (lists, Search, Pulse). ### Related issue Related to #2910 (default "Fizz" agents from different users collide in one channel). ### Testing - The contract's 31 portable fixture cases run against the production resolver. The fixture file is copied unchanged from the contract, so reviewers can skip it. - Unit tests cover owner and suffix qualification, the viewer's own identities, and invalid public keys. - Provider tests check that a channel keeps its names while its roster reloads, that an offline cached bot still counts as an agent, and that changing relay or account never shows the old roster. - `flutter analyze` is clean. No UI change, so there are no screenshots. --------- Signed-off-by: Logan Johnson <[email protected]> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> * docs: specify desktop-driven mobile push suppression (#7809) ## Summary Define when desktop activity suppresses otherwise eligible mobile message notifications: a ten-minute inactivity window, short-lived relay-owned suppression, and per-installation push preferences. Include a shared glossary and renewal timing diagram. The gateway remains unaware of suppression. This is a design draft ready for review, not an implementation-ready protocol. Wire format, synchronization, and several failure-handling details remain explicitly open. Please also review the tension between the agreed relay-confirmed preference changes and VISION_MOBILE.md's requirement that stopping notifications must not depend on a relay response. ### Related issue Related: #3234 covers per-channel notification settings and push filtering; this spec focuses on desktop-activity suppression. No duplicate spec PR found. ### Testing Documentation-only change. Local Markdown links and anchors resolve; whitespace validation and commit hooks passed. The full local CI gate could not complete: dependency compilation exhausted local disk space (OS error 28). GitHub checks currently report no failures. --------- Signed-off-by: Tom Brow <[email protected]> Co-authored-by: Diem Nguyen <[email protected]> * docs(nips): fix stray angle brackets in created_at clauses (#4486) ## Summary The `<` in a `created_at<` condition is the comparison operator, but in three places it had been paired with a closing `>` as if it opened a `<placeholder>` bracket: - **NIP-OA** clause list: `created_at<unix-timestamp>` → `created_at<unix-timestamp` - **NIP-OA** satisfaction rule: `created_at<t>` → `created_at<t` - **NIP-GS** "Conditions in Git Context": `created_at<t>` → `created_at<t` (line 437 of the same file already used the correct form) This matches the `created_at>...` forms used alongside them, which never carried a closing bracket. Also normalizes the NIP-OA headings to ATX style and pretty-prints the signed-event JSON example for readability. ## Verification Docs-only change. The NIP-OA test vectors are untouched and were re-verified by recomputing them: the preimage SHA-256, `tag-bytes-hex`, and the signed-event `id` all still match the documented values. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: zmeyer44 <[email protected]> Co-authored-by: Claude Fable 5 <[email protected]> * feat(web): add Browse releases link next to invite download (#2255) Related to https://github.com/block/buzz/issues/2093 Invite pages offered a platform-resolved binary download with no path to the GitHub releases listing for users who wanted information first. ### Changes - Keep the smart **Download it now** CTA - Add an always-visible **Browse releases** link pointing at `https://github.com/block/buzz/releases` - Extend invite smoke coverage for the new link Note: the marketing-site “Get the App” button on buzz.xyz appears to live outside this repository; this improves the in-repo web invite flow. Signed-off-by: Ian Alloway <[email protected]> Signed-off-by: Fizz <300bd4cedcdddb62f77935de51c301034bdb4cd97da9aaca46d59673a1ebc7cf@buzz.block.builderlab.xyz> * feat(buzz-relay): NIP-FI stateless enforcement (S3) — upgrade gate, NIP-42 pairing, session lifetime, JWKS warm (#7224) ## What this PR does Implements NIP-FI stateless enforcement at the relay WebSocket upgrade point. Every connection attempt on a NIP-FI–enabled relay must carry a valid federated identity assertion signed for the connecting Nostr pubkey; the relay validates it before the first frame is read, pairs it with NIP-42 AUTH, and enforces a bounded session lifetime without persistent state. ### Core enforcement seam - **Assertion at upgrade** (`nip_fi_upgrade.rs`): identity header is parsed with the same `extract_bearer_token` and denied with the same `http_denial` as HTTP ingress (`nip_fi_http.rs`), JWT verified (RS256/ES256/EdDSA), expiry checked, and the Nostr pubkey embedded in the sub claim must match the NIP-42 AUTH pubkey that arrives in the socket within the AUTH timeout. Denial returns exact byte contracts — `401 + WWW-Authenticate: Nostr + "authentication required\n"` for missing evidence, `403 + "evidence rejected\n"` for malformed or invalid evidence. The active HTTP/1.1 gate runs before `bind_community`, so denied upgrades pay zero DB cost. - **NIP-42 pairing** (`nip_fi_gate.rs`, `audio/handler.rs`): after the assertion is validated at upgrade, a `SessionAdmissionGate` is created with the assertion's expiry deadline and a `CancellationToken`. The gate is passed to every effect-acquiring path so no new effect permit is granted after the session expires. AUTH is verified against the assertion pubkey; a mismatched AUTH key receives `NOTICE restricted: authorization denied` and a socket close. Every other post-upgrade AUTH denial on an FI connection uses the same terminal shape — the canonical spec NOTICE on the terminal queue, then close — so frame type and close behaviour reveal nothing about private policy: ban, allowlist, or relay-membership denial → `restricted: authorization denied`; ban/allowlist/membership lookup failure or an internal verifier failure → `restricted: authorization unavailable`; an invalid NIP-42 proof → `restricted: evidence rejected`. Connections without an assertion keep today's `OK false` replies. - **Session lifetime** (`nip_fi_session.rs`): three independent deadlines bound each session — token `exp`, max assertion age from config, and relay max connection lifetime. The first to fire cancels the gate and sends the terminal denied frame. - **Effect admission at expiry** (`audio/join.rs`, `handlers/req.rs`): no new effect permit is granted after expiry. Two paths carry calculated budgets. The audio **lease resolver** holds its permit for at most `worst_case::PERMIT_HOLD` (14.5 s), and cancellation **during that resolver** reaches socket close within `worst_case::EXIT` (25 s: resolver, release of the won lease, terminal flush). Redis checkout has one total deadline and directory scripts are single-round-trip `EVAL`, which is what makes those budgets hold. When post-write fence verification fails after a landed CAS, the acquire keeps the reply and attempts an exact owner+generation cleanup on the same connection without a serving-write lease; if that cleanup fails or its reply is uncertain, the lease expires by its 30 s TTL. Neither number bounds audio close in general: other admission and teardown waits (for example the channel lookup after the resolver) and the known limitations below have no client-side deadline. REQ liveness, search and history reads race gate cancellation: a lost race drops the read, releases the permit, retires the claim through `close_if_owner`, and sends no further EVENT or EOSE. A history statement timeout ends the read with a timed-out outcome, and its owner-checked retirement (`CLOSED`, map, index and topic release) runs after the race with the permit dropped, so cancellation cannot drop it halfway. Subscription registration stays one uncancellable unit, and the permit is still taken before the claim. - **JWKS recovery** (`main.rs`): builds on main's `warm_nip_fi_jwks_snapshots` / `nip_fi_jwks_refresh_loop`. Issuers warm concurrently and the first refresh is seeded from the warm result (one interval for a warm issuer, 5 s for a cold one). A refresh that finds no live snapshot retries at the fast cadence (5 s after a warm issuer dies, doubling to a 300 s cap) instead of waiting a full interval, and `run_jwks_refresh_supervisor` restarts the loop after a panic (1 s → 60 s backoff); On shutdown it is cancelled and awaited before the drain backstop is disarmed; cancel drops an in-flight fetch and starts no further issuer, so the join stays inside the drain bound. Logs carry `issuer_index` only. ### Known limitations - **Known limitations: bounded only by the dependency.** No new effect is admitted after expiry. Two awaits that are already admitted have no client-side bound, so if a dependency stalls at expiry, teardown waits for it: - **Audio join commit:** its effect permit spans `tx.commit()`, room publication and the `event_mentions` insert. During a DB or Redis stall, audio cleanup and socket close wait for the dependency. - **REQ subscription setup:** the first subscriber to a topic sends `Subscribe` to the pubsub task through a bounded channel (capacity 4096). The send blocks only if that queue is full, which happens when the pubsub task isn't keeping up (for example during reconnect backoff or a burst). Registration holds the connection's `conn.subscriptions` lifecycle lock across the send, so a blocked send also blocks other claims on that connection, including search, and any cleanup waiting on that lock. The send itself predates this PR; holding the REQ permit across it is new here. ### Archive/join serialization `commit_participant_join` now takes a row-level write lock (`SELECT ... FOR NO KEY UPDATE`) on the channel row at step 3. This serializes all join commits against concurrent `archive_channel` calls — the archive UPDATE (`archived_at` non-key column) blocks on the row lock, closing the READ COMMITTED race on both the `Existing` and `AutoAddRequired` paths. ### HTTP/2 extended-CONNECT gate (latent path) The root WebSocket handler uses a belt-and-suspenders approach. The HTTP/1.1 path (currently the only live WebSocket shape — workspace Axum does not enable `http2`) is gat…

TheSentinel454 force-pushed the tornquist/relay-readiness-overload branch from 25bc2c2 to a8e2c48 Compare September 4, 2026 20:04

TheSentinel454 marked this pull request as ready for review September 15, 2026 09:35

TheSentinel454 requested a review from a team as a code owner September 15, 2026 09:35

TheSentinel454 requested a review from kalvinnchau September 15, 2026 09:37

kalvinnchau previously requested changes Sep 16, 2026

View reviewed changes

Comment thread crates/buzz-relay/src/state.rs Resolved

Comment thread crates/buzz-relay/src/readiness.rs Resolved

Comment thread crates/buzz-relay/src/router.rs Resolved

TheSentinel454 requested a review from kalvinnchau September 22, 2026 20:30

wesbillman requested changes Sep 24, 2026

View reviewed changes

Comment thread crates/buzz-relay/src/readiness.rs Resolved

Comment thread crates/buzz-relay/src/router.rs Resolved

TheSentinel454 commented Sep 24, 2026

View reviewed changes

Comment thread crates/buzz-relay/src/readiness.rs Resolved

wpfleger96 requested changes Sep 24, 2026

View reviewed changes

TheSentinel454 commented Sep 24, 2026

View reviewed changes

Comment thread crates/buzz-relay/src/readiness.rs Resolved

wesbillman previously requested changes Sep 25, 2026

View reviewed changes

Comment thread crates/buzz-relay/src/readiness.rs Resolved

wpfleger96 previously requested changes Sep 25, 2026

View reviewed changes

wesbillman reviewed Sep 25, 2026

View reviewed changes

Comment thread deploy/charts/buzz/README.md Resolved

wesbillman reviewed Sep 25, 2026

View reviewed changes

wpfleger96 reviewed Sep 25, 2026

View reviewed changes

wesbillman reviewed Sep 25, 2026

View reviewed changes

Comment thread crates/buzz-relay/src/readiness.rs Resolved

wpfleger96 reviewed Sep 25, 2026

View reviewed changes

TheSentinel454 force-pushed the tornquist/relay-readiness-overload branch from 83e4975 to 91e5f96 Compare September 25, 2026 19:45

wpfleger96 reviewed Sep 25, 2026

View reviewed changes

wesbillman reviewed Sep 25, 2026

View reviewed changes

TheSentinel454 and others added 7 commits September 28, 2026 14:19

test(relay): cover Redis bootstrap timeout

54414ff

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]> Signed-off-by: tornquist <[email protected]>

Fix relay permissions in PostgreSQL CI

5f06add

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]> Signed-off-by: tornquist <[email protected]>

fix(relay): sample readiness once per probe

63bc7b4

Co-authored-by: Codex <[email protected]> Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Signed-off-by: tornquist <[email protected]>

TheSentinel454 and others added 7 commits September 28, 2026 14:20

fix(relay): retain readiness completion timestamp metric across idle …

6817409

…cleanup Signed-off-by: tornquist <[email protected]> Co-authored-by: Amp <[email protected]> Signed-off-by: tornquist <[email protected]>

test(ci): include relay readiness and router unit selectors

382223a

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]>

relay readiness: keep completion epoch as gauge with republisher

4b00d0c

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]> Signed-off-by: tornquist <[email protected]>

fix(relay): unify readiness sampler+publisher startup seam

a566a29

Signed-off-by: tornquist <[email protected]> Co-authored-by: Amp <[email protected]> Signed-off-by: tornquist <[email protected]>

fix(relay): reuse readiness runtime runners

c58cee5

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]> Signed-off-by: tornquist <[email protected]>

test(relay): bound readiness sampler startup wait

b96aa84

Signed-off-by: tornquist <[email protected]> Co-authored-by: Codex <[email protected]> Signed-off-by: tornquist <[email protected]>

TheSentinel454 force-pushed the tornquist/relay-readiness-overload branch from 91e5f96 to b96aa84 Compare September 28, 2026 14:42

TheSentinel454 requested review from wesbillman and wpfleger96 September 28, 2026 14:49

wesbillman reviewed Sep 28, 2026

View reviewed changes

wpfleger96 reviewed Sep 28, 2026

View reviewed changes

wpfleger96 approved these changes Sep 28, 2026

View reviewed changes

TheSentinel454 merged commit b37e477 into main Sep 28, 2026
90 checks passed

TheSentinel454 deleted the tornquist/relay-readiness-overload branch September 28, 2026 18:02

wpfleger96 mentioned this pull request Sep 28, 2026

Schedule the deletion drain safely #7827

Merged

wpfleger96 mentioned this pull request Sep 28, 2026

Automate owner deletion preparation #7830

Merged

Areson mentioned this pull request Sep 28, 2026

fix(db): audit partition catalog before creation #6515

Merged

github-actions Bot mentioned this pull request Sep 30, 2026

[Buzz update] desktop-v0.5.26 available BrianInAz/buzz#46

Open

RossHartmann mentioned this pull request Oct 16, 2026

Sync upstream block/buzz main (97e1f6a0) into the Kiingo fork — DO NOT MERGE until main's go Kiingo/buzz#202

Merged

Conversation

TheSentinel454 commented Sep 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Related issue

Tradeoff

Testing

Complexity

Uh oh!

github-actions Bot commented Sep 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔐 Codex Security Review

Uh oh!

kalvinnchau left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wpfleger96 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wpfleger96 left a comment

Choose a reason for hiding this comment

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TheSentinel454 commented Sep 25, 2026

Gimli E2E verdict — exercised and works

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

wpfleger96 left a comment

Choose a reason for hiding this comment

Uh oh!

TheSentinel454 commented Sep 25, 2026

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wpfleger96 left a comment

Choose a reason for hiding this comment

Uh oh!

wpfleger96 left a comment

Choose a reason for hiding this comment

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

wpfleger96 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

TheSentinel454 commented Sep 4, 2026 •

edited

Loading

github-actions Bot commented Sep 4, 2026 •

edited

Loading