## 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 <tornquist@squareup.com>
Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Amp <amp@ampcode.com>
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 <pfleger.will@gmail.com>
Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz>
Bind each context-menu interaction to the exact mock message returned by the emitter so same-second ordering cannot select the wrong video.
Co-authored-by: Codex <noreply@openai.com>
Signed-off-by: tornquist <tornquist@squareup.com>
Distinguish the disabled Kubernetes API token mount from provider workload-identity credentials while retaining the dedicated service-account recommendation.
Co-authored-by: Codex <noreply@openai.com>
Signed-off-by: tornquist <tornquist@squareup.com>
Share a suffix-preserving 52-character name helper between the deletion drain and storage accounting CronJobs while retaining their existing short names.
Co-authored-by: Codex <noreply@openai.com>
Signed-off-by: tornquist <tornquist@squareup.com>
Exercise both supported credential shapes through the CI render matrix and bind the typed job guards, schema boundary, pod identity, and default sidecar annotation.
Co-authored-by: Codex <noreply@openai.com>
Signed-off-by: tornquist <tornquist@squareup.com>
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`
## 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>
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.
<!-- buzz-review-completed -->
---------
Signed-off-by: Tom Brow <tomb@block.xyz>
A documentation-only update to #7809 selected desktop builds and E2E
tests because path detection compared an old PR base SHA with GitHub's
newer synthetic merge commit. The [failing run's path-detection
log](https://github.com/block/buzz/actions/runs/35789957773/job/106955810630)
includes four unrelated desktop files from `main`; `VISION_MOBILE.md`
did not match a runtime filter.
Use GitHub's PR file list for pull requests so unrelated changes in the
synthetic merge commit cannot select runtime suites. The existing
directory filters are unchanged: root and docs/ Markdown do not select
runtime suites, while Markdown under runtime directories still selects
its affected suites. Mixed code/documentation changes retain normal
coverage. Always-on security, policy, and source-contract checks and
full push-to-main coverage are unchanged.
Added regression coverage runs the pinned paths-filter action against
real fixture repositories, including a synthetic merge containing
unrelated upstream desktop code. All 35 selection scenarios and 26
required-check scenarios pass; the new regressions failed before the
fix. Existing required-context isolation, file-size policy, and
security-review contract checks pass, as do script lint and workflow
syntax validation. Full workflow lint reports the same two pre-existing
shell-quoting findings in the untouched dead-token guard. A desktop E2E
build was run to diagnose the unrelated required smoke failure.
Related: #7809 (incident, unchanged) and #5756 (shared-input path
coverage, separate scope). No matching issue found.
PRs with at least 3,000 changed files now select every runtime suite,
avoiding GitHub's PR-file-list ceiling. Boundary tests cover 2,999,
3,000, and 3,001 files, including a runtime file omitted beyond the API
cap; disabling the safeguard makes the latter two regressions fail.
Required checks now run and fail when path selection fails, is
cancelled, or is skipped. Regression coverage exercises the workflow
conditions and shell checks for all 13 required wrappers, plus an
API-denial case against the pinned action. Mutating either the
scheduling guard or the result check makes all 13 failure regressions
fail.
The required mention-settings smoke test expected a pin after explicitly
disabling automatic mentions. Waiting for its old avatar to exit
reproduced the CI failure 3/3; the test now checks that subsequent
mentions remain manual and retains outgoing recipient-tag assertions.
Corrected browser regression: 20/20 repeated runs; related picker unit
tests: 18/18. No desktop production behavior changed. The always()
requirement is now pinned in required-wrapper regression tests; deleting
it fails all 26 gate cases.
---------
Signed-off-by: Tom Brow <tomb@block.xyz>
## Summary
Fix the upload/edit smoke-test race observed on main at
`6410e685a80d42db0645fadc9bbe710559ef911e`.
- Hold the mock upload at the Tauri IPC boundary and release it
explicitly after checking edit rejection, rather than assuming menu
interaction finishes within one second.
- Wait for the Radix menu to unmount: edit dispatch happens in
`onCloseAutoFocus`, after the click. Without that wait, the negative
assertion can pass before the edit callback actually runs.
- Keep the existing attachment-preservation and subsequent
successful-edit assertions. No production code or CI coverage is
changed.
## Evidence and scope
- [Main
failure](https://github.com/block/buzz/actions/runs/36189213149/job/108250341388):
`opening edit during an immediate photo upload preserves the draft`,
including an upload-progress timeout on retry.
- Investigated from #7791, which changes only `docs/nips/NIP-AR.md`. Its
PostgreSQL failures and video-menu timeout are separate; PostgreSQL
passed on this main run, and the video spec passed locally. This PR does
not claim to fix those failures or the separate pointer-interception
failure seen in the main job.
- #7843 already addresses unrelated runtime suites being selected for
docs-only PRs.
## Validation
- Full desktop `pnpm test`: 6,676 Node tests + 92 jsdom tests passed.
- Upload/edit regression repeated 5 times: passed. Holding the upload
without waiting for menu teardown failed all 5 runs, demonstrating the
second race.
- Complete file-attachment and video-attachment Playwright specs: 30
passed.
- Pre-push desktop lint, typecheck, full desktop tests, and file-size
gate passed at `46e3d4392e5b56dcb74ea864aa19aa10287f27d3`.
- `just ci` attempted: initial formatting issue corrected; second run
exceeded the 5-minute local limit during Tauri clippy. Not claiming full
repository CI green.
## Review / human verification
Self-reviewed the diff against the test contract; no production behavior
changes. Draft pending human verification and CI.
To verify: activate Hermit, then `cd desktop && pnpm test:e2e:smoke
file-attachment.spec.ts --grep "opening edit during" --repeat-each=5`.
Expect all five runs to pass, retaining the upload in the draft and
allowing edit only after upload release.
Originating conversation:
buzz://message?channel=aa7f2b48-d367-4ca1-be09-116a2eb45b99&id=1b68585ba4483a87f5a453fd7bbdd11d434e332dcb4aff8acfe1f5d2601b6561
Signed-off-by: Smartie <fb3185faacfc3760b6b4fe0085a8878d8dd537f7a7671c7d3184fe1aa1b04df4@buzz.block.builderlab.xyz>
Co-authored-by: Smartie <fb3185faacfc3760b6b4fe0085a8878d8dd537f7a7671c7d3184fe1aa1b04df4@buzz.block.builderlab.xyz>
Implements NIP-FI HTTP ingress enforcement per the merged spec (PR
#7254). Every protected HTTP surface in enforce mode requires a valid
`Nostr-Federated-Identity: Bearer <JWS>` assertion alongside its NIP-98
authorization, bound to the same key. The NIP-98 pubkey (proven actor)
must equal the assertion's `nostr_pubkey`; absent, mismatched, or
unverifiable assertions are denied fail-closed with byte-exact
text/plain responses per the spec's rejection table.
This is S5 of the `buzz-enterprise-identity` program. WS enforcement
(S3) is separate.
## What changed
**New `nip_fi_http` module:** `admit_nip_fi_http()` covers the full
admission sequence — `Nostr-Federated-Identity` extraction, offline JWKS
verification, NIP-98 key pairing [FI-INV-05], issuer-qualified deny-map
check via `(iss, pubkey, now)` [FI-INV-14], and byte-exact denial for
all four `DenialClass` variants. `admit_nip_fi_http_on_state()` is the
single call-site wrapper for all surfaces [FI-TRACE-AUTHORITY-UNIFORM].
**Protected surfaces** (all gated via the uniform authority):
- HTTP bridge: `POST /events`, `/query`, `/count`
- GIF proxy: `POST /gifs/search`, `/gifs/share`
- Workflow reads: `GET /workflows/{id}/runs`, `GET
/workflows/{id}/runs/{id}/approvals`
- Moderation reads: `GET /moderation/reports`, `/moderation/audit`,
`/moderation/restricted`
- Media/Blossom: `PUT /upload`, `/media/upload`
- Git smart-HTTP: `info/refs`, `upload-pack`, `receive-pack`
- Git settings control plane: `GET`/`POST
/git/:owner/:repo/default-branch` (now routed through
`admit_nip_fi_http_on_state` for full assertion key-pairing)
- Invites: `POST /api/invites` (mint only; claim exempt as
pre-membership enrollment door)
**NIP-98 strictness in NIP-FI mode:**
- When NIP-FI is not Off, bridge POST handlers force `require_auth_token
= true` — the `X-Pubkey` dev-mode fallback cannot satisfy the pairing
requirement [NIP-FI.md:547-567]
- POST bodies on `/events`, `/query`, `/count` require a matching
`payload` tag in enforce mode [NIP-FI.md:579-597]
- A payload tag present with no content (one-element `["payload"]` or
empty string) is rejected as a structurally invalid claim — NIP-98
requires the content to be a valid 64-char lowercase hex SHA-256 digest.
Malformed payload diagnostics use a static error message (no
attacker-controlled content in logs).
- Off mode preserves pre-NIP-FI behavior per [FI-INV-15]
**Off-mode compatibility changes:** Admission now runs before request
validation on every protected surface, so Off mode differs from
pre-NIP-FI behavior in these ways:
- **GIF routes:** NIP-98 authentication happens before the upstream
provider lookup. An unauthenticated request on a tenant with no GIF
provider now returns 401 instead of 404. The 401 goes through the legacy
`api_error()` path, so the body is JSON `{"error":"..."}` with no
`WWW-Authenticate` header.
- **Workflow runs** (`GET /workflows/{id}/runs`): the query string is
parsed after admission. A request with a missing credential and a
malformed query (for example `?limit=abc`) now returns 401 instead of
400.
- **Authorized malformed query:** once admitted, a malformed query
returns a JSON 400 `{"error":"invalid query: ..."}` from
`parse_query_or_400` instead of axum's `text/plain` `Query` rejection.
- **Moderation reads** (`/moderation/reports`, `/moderation/audit`):
same extraction change as workflow runs. Admission comes first, then a
JSON 400 for a malformed query.
- **Malformed `payload` tag:** shared NIP-98 verification now rejects a
malformed `payload` tag in every mode, including on bodyless requests.
That means a one-element `["payload"]`, an empty digest, or anything
other than 64 lowercase hex characters. Before this change, a bodyless
request ignored the tag.
**Auth header cardinality:** Enforce mode rejects requests with more
than one `Authorization` header with 403 `evidence rejected\n`.
DenyProtected returns 503 `authorization unavailable\n` before this
check (and before NIP-98 or assertion verification) runs. The
cardinality gate is enforced at the NIP-FI admission boundary
(`admit_nip_fi_http`), not via legacy auth boolean flags, so it applies
uniformly to all Enforce-mode surfaces including Git. Off mode passes
through the first header value unchanged, preserving pre-NIP-FI behavior
[FI-INV-15].
**Denial-class remapping:** In Enforce mode, NIP-98
extraction/verification failures from the closure are mapped to the
appropriate `DenialClass`: `MissingEvidence` when no `Authorization`
header is present, `EvidenceRejected` when the header is present but
invalid. Off mode propagates legacy responses unchanged [FI-INV-15]; for
example, the Git missing-Authorization and wrong-scheme 401s keep their
legacy bytes with no `content-type` header.
**JWKS refresh scheduling:** The refresh timer's `*last` checkpoint is
set after the fetch completes, not from the pre-fetch timestamp,
preventing interval drift under network latency. The loop is extracted
to `nip_fi_jwks_refresh_loop` for unit-testability.
**Log hygiene [NIP-FI.md:777-779]:** Issuer identity is never written to
logs or error messages. All startup/refresh diagnostics use an ordinal
index (`issuer_index = N`). Config parse errors for malformed issuers
use classify()/line/column codes rather than raw config values.
**Admin SPA document routes:** `/reports`, `/reports/{id}`, and
`/feedback` are exempt from the NIP-FI assertion guard only on the admin
host (host-qualified via `is_admin_host`). These paths are not added to
the broad `NIP_FI_EXEMPT_PREFIXES` list — tenant hosts remain fully
protected.
**Deny-map seam (`HttpDenyMap` trait):** signature is `(issuer, pubkey,
now)` matching `NipFiDenyMap::is_denied` from S4 (PR #7265) so
integration is a one-liner. Stub is `AlwaysAdmitStubDenyMap` — named to
accurately describe stub-phase semantics (fail-open intentionally
pending S4).
**Route inventory:** every authenticated HTTP route is classified as
Protected or Exempt with justification. Documented in the F4 seam-test
comment in `bridge.rs`.
**Outer-guard tests:** `#[ignore = "requires Postgres"]` tests in
`bridge.rs` drive the full router (`build_router`) in Enforce mode with
valid NIP-98 but no `Nostr-Federated-Identity` header. These exercise
the **outer `nip_fi_assertion_guard` middleware** in `router.rs` — the
layer that fires before any handler runs. They prove the guard's exact
response bytes (401 `authentication required\n`, `text/plain;
charset=utf-8`, `WWW-Authenticate: Nostr`) for each protected route.
Per-handler `admit_nip_fi_http_on_state` wiring is proven separately by
the cardinality test and the media/settings/git handler-level suites.
## Seams
**S3 seam:** `nip_fi_config.rs` is duplicated (S3 not landed;
session-deadline parts stripped). Removed when S5 rebases onto S3.
**S4 seam:** `AlwaysAdmitStubDenyMap` until S4 provides the real map.
Integration is one line at the `admit_nip_fi_http_on_state` wrapper.
## Evidence
At head `ee338ea9c` (branch `hayt/nip-fi-http-enforcement`), hosted CI
run
[36167450853](https://github.com/block/buzz/actions/runs/36167450853):
- **Rust / Unit Tests** ([job
108179338458](https://github.com/block/buzz/actions/runs/36167450853/job/108179338458)):
passed. The `buzz-relay` `test-unit` step ran 171 tests with 171 passes.
Its PASS lines include all 57 non-ignored tests this PR adds to the
relay: `nip_fi_http::tests` (25), `nip_fi_config::tests` (8),
`router::tests` (8), `api::parse_query_tests` (5),
`api::transport::off_mode_precedence_tests` (5),
`tests::jwks_refresh_*` (3), and `composition_tests` (3). The same job
ran the `buzz-auth` suite, which includes
`nip_fi::jwks::tests::key_set_serves_live_snapshot_under_reader_and_refresh_overlap`.
- **Rust / Rust Lint**: passed.
- **Relay and PostgreSQL / Backend Integration (relay e2e)**: passed.
- **PostgreSQL Domain / PostgreSQL Tests** ([job
108183303436](https://github.com/block/buzz/actions/runs/36167450853/job/108183303436)):
passed. 542 tests run, 542 passed.
---------
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Hayt <9e1c23a3fd83f61da34420e4e88ff1b16e45cafcc0cd9019eb07d4ecfa8ca9b0@buzz.block.builderlab.xyz>
Signed-off-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz>
Co-authored-by: Hayt <9e1c23a3fd83f61da34420e4e88ff1b16e45cafcc0cd9019eb07d4ecfa8ca9b0@buzz.block.builderlab.xyz>
Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz>
Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
`api::admin::postgres_tests::disabled_mode_allows_unauthenticated_requests_on_the_admin_host`
falls through to a DB-backed read route but was not `#[ignore]`d. The
`test-unit` exclusions meant to skip it still named
`api::admin::tests::…`, which stopped matching when #6730 moved the
admin tests into `mod postgres_tests`. As a result the test ran in the
infra-free unit job and only passed after waiting out the sqlx acquire
timeout (~150s in hosted CI), while the ignored-only PostgreSQL lane
never ran it against a real database.
- The test is now `#[ignore = "requires PostgreSQL"]`, like its
DB-backed peers, so the PostgreSQL lane runs it.
- The two dead exclusions are removed, and the `api::admin` clause is
just `test(/^api::admin::/)`.
`nip98_mode_unrostered_signer_does_not_consume_a_replay_slot` was
already ignored and runs in the PostgreSQL lane.
- The `Justfile` comment now states the convention (DB-backed admin
tests are ignored; non-ignored ones reject before touching the DB),
drops the stale reference to a ci.yml step that no longer exists, and
keeps the timeout-trap warning.
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz>
Adds a "Before opening a PR" checklist and "Reviewing" guidance to
`AGENTS.md`, and makes the Review-Proven Rules the shared reviewer
checklist.
PRs stay in draft until an agent review has run, an agent has exercised
the change on the affected surface, and a human has tested it. The
review-completed passphrase goes in the description only once that
checklist holds for the current change, and comes out if later edits
change behavior. Docs-only changes use the light path: content, link,
and diff checks plus human confirmation.
Reviews read `VISION.md` and the surface's `VISION_*.md` first, check
the change against the Review-Proven Rules, recommend blocking only for
concrete correctness, security, or contract defects with a realistic
failure, label everything else optional, and put all findings in the
first pass. Agents comment and never use Request Changes; humans decide
which findings must be fixed.
Related:
[block/buzz-app#268](https://github.com/block/buzz-app/pull/268)
---------
Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
The runbook told operators to target `cronjob/<release>-buzz-deletion-drain`.
`buzz.fullname` collapses to the release name when it already contains the
chart name, so the documented name is wrong for the documented install:
`helm install buzz ...` renders `buzz-deletion-drain`. Discover the CronJob by
its component label instead, and describe the name rule rather than a single
guessed spelling.
Three more corrections:
`activeDeadlineSeconds` was presented as if a timed-out run were just another
retry. It is not recorded as one — shutdown releases the claim without
recording a retry, and only the object-store drain resumes mid-stage — so a
deadline landing repeatedly inside a non-resumable stage loops forever with a
rising `attempts`, a flat `retry_count`, and no block. Document how to spot
that from both the request and Kubernetes, how to size the deadline, and how
to recover.
`terminationGracePeriodSeconds` was presented as a clean handoff. Document
that a pod still working at the end of the window is SIGKILLed holding its
lease, and that recovery is lease expiry plus reclaim under a new generation.
An empty `serviceAccountName` was described as a neutral default. It inherits
the relay's service account; `automountServiceAccountToken: false` hides the
projected token but does not detach cloud IAM bindings resolved through the
node metadata path. Recommend a dedicated pre-created account when the
executor's IAM blast radius should be smaller than the relay's.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: tornquist <tornquist@squareup.com>
The admission path reads as if the relay had verified the owner's consent.
It has not: the mediating operator authenticates the owner and collects
the acknowledgement out of band, and the request reaching the relay
carries only that operator's NIP-98 signature. The relay checks operator
authority and current ownership, and stores the owner pubkey, operator
pubkey, and acknowledgement version as provenance for the upstream
ceremony — never an owner-signed attestation.
Also record how manual handoff converges. Owner provenance pins
`requested_by` to `owner_pubkey`, so `buzz-admin deletions submit` must
repeat the owner pubkey to adopt an admitted request; the operator's own
pubkey conflicts with the one-active-request invariant instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: tornquist <tornquist@squareup.com>
`/operator/communities/delete` admits an irreversible request, but the
endpoint's own tests only exercised the happy path and relied on generic
operator-auth coverage elsewhere. Nothing pinned that this route refuses
an unsigned caller, the X-Pubkey dev fallback, a non-operator signer, or
a signature bound to a different method, URL, or body.
Add direct coverage for each binding failure, and for idempotent replay:
an identical resubmission converges on the stored request, while a
resubmission that changes the owner, the host, or the acknowledgement
version is refused and leaves the stored intent untouched. Every
rejection asserts no deletion request was persisted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: tornquist <tornquist@squareup.com>
The malformed-body coverage sent a single request carrying several
invalid fields at once, including an unparseable `request_id`. Request
deserialization runs before the host and pubkey guards, so that request
was refused by serde and the guards it claimed to cover were never
executed — dropping the `owner_pubkey` validation entirely left the test
passing.
Give each guard its own request whose remaining fields are valid, so the
case reaches the guard under test, and assert no deletion intent
persists for any refusal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: tornquist <tornquist@squareup.com>
The owner branch of community_deletion_owner_provenance tested only the
shape of each provenance column. A bare `col ~ '...'` on a NULL column
evaluates to NULL, and a CHECK constraint is satisfied by NULL, so
`FALSE OR NULL` admitted owner-origin rows with no owner key, no
mediating operator, or no acknowledgement version.
Reject a NULL in each column before testing its shape. Spell it
`NOT (col IS NULL)`: pgschema drops a named CHECK whose body contains
`IS NOT NULL` and still exits 0, which would leave the desired-state
bootstrap silently unguarded while the migration path stayed correct.
Assert one shared case table from both schema sources -- the migration
upgrade path and the pgschema desired-state bootstrap -- so the two
cannot drift into different owner-provenance guarantees.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: tornquist <tornquist@squareup.com>
Owner admission records durable intent with no owner-facing cancellation,
so an operator needs a recovery path when preparation cannot continue.
Abort already reversed approved and fenced requests; extend it to the
submitted and inventoried stages, which have destroyed nothing.
Aborting releases the durable request fence over owner listing,
unarchive, and owner rotation. It reverses deletion intent only: the
community stays archived and the owner restores it explicitly. Stages
from drained onward stay closed.
Lock ordering and the active-serving-write-lease guard are unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: tornquist <tornquist@squareup.com>
## Why
Data backfills need a durable contract outside schema migrations. The
contract must survive crashes and support automatic or manual operation
without adding version-selection machinery.
## What
- Define one PostgreSQL-backed lifecycle for finite data repair
- Treat the stable backfill ID as the only durable execution and
readiness identity
- Use eventually consistent, idempotent registration; compatible workers
compete for one exclusive claim
- Require bounded batches, atomic mutation and checkpoint commits,
generation fencing, and validation before completion
- Define all four migration and automatic-backfill configurations
- Define the authorized admin API and honest client projection
## How
A backfill captures one immutable upper bound, processes finite batches,
and commits each target mutation with its checkpoint. PostgreSQL owns
lifecycle state, claims, progress, and completion.
Registration order and build metadata do not choose a definition.
Compatible processes are interchangeable. A material behavior change
requires a new stable ID. The orchestrator does not resolve different
behavior registered under one active ID. Diagnostic validation on
completed rows records only its bounded outcome and audit; it does not
create an execution claim.
The spec now starts with a six-step mental model and follows the
operator flow. It removes repeated requirements and cuts the document
from 614 lines and 4,835 words to 474 lines and 3,656 words.
## Risk
Low. This PR changes documentation only. It commits Buzz to a design
contract, but it does not add runtime, schema, configuration, or
protocol behavior.
## Testing
No manual runtime testing. A fresh full-spec review checked the
lifecycle, safety rules, four configuration cells, admin contract, and
production-seam conformance requirements. `git diff --check` and the
repository file-size policy pass at
`13681664674d4667b181a6211f012090fa40a2cf`.
## Bigger picture
The design keeps the relay as orchestrator, a focused backfill crate as
domain owner, and `buzz-db` as narrow transaction infrastructure. It
removes deployment generations and definition precedence from the
implementation plan.
Generated with Codex
---------
Signed-off-by: tornquist <tornquist@squareup.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Adds a short paragraph to the Protocol section of `VISION.md` about
`/buzz/v1` endpoints, which are backend-for-frontend (BFF) reads.
- **Dividing line:** every write is a signed Nostr event. Nostr reads
must cover all of that state. `/buzz/v1/...` can add reads shaped for
specific use cases (thread catch-up, sync) over the same store.
- We start with this rule and refine it as more exceptions come up.
## What
Two fixes to `crates/buzz-db/src/store/relay_admin_actions.rs` and one
cleanup in `crates/buzz-db/src/store/thread.rs`.
### 1. Thread counter atomicity
The admin delete action now calls the canonical
`soft_delete_event_and_update_thread_in_tx` body shared with NIP-29 and
NIP-09 event-ID deletion. The delete, parent `reply_count` decrement,
root `descendant_count` decrement, and step marker commit or roll back
together in one transaction. A second action against an already-deleted
target is a no-op and does not double-decrement. After a committed
delete, `emit_live_thread_summary` refreshes the live thread count the
same way `DELETE_EVENT` does.
### 2. Lock-first lease expiry fence (all five admin-action paths)
On main, the final marker `UPDATE` in every admin-action path
(`execute_ban_with_marker`, `execute_timeout_with_marker`,
`execute_kick_with_marker`, `execute_delete_with_marker`,
`record_failure`) checks `clock_timestamp()` in the `WHERE` clause.
PostgreSQL can evaluate that predicate before waiting to lock the target
row. If another transaction holds the action row and releases it
unchanged after the lease expires, the update commits under the stale
timestamp.
On this branch, each path acquires the action row with `SELECT … FOR
UPDATE` inside the same transaction before any domain write. The
wall-clock expiry check in the marker `UPDATE` runs after that lock is
held, not before. The pre-entry ownership `SELECT EXISTS` checks remain
— they are early-rejection optimizations that are safe because the
correct final fence rolls back any provisional work.
`record_failure` on main uses a single-statement `execute(pool)`. On
this branch it begins a transaction, acquires the row lock with `SELECT
… FOR UPDATE` and an explicit expiry check, then writes `state =
'failed'` — matching the four mutation functions.
**Lease validity is checked at the protected ownership check under the
action-row lock, not at physical `COMMIT` completion.**
| Function | Change |
|---|---|
| `execute_ban_with_marker` | `SELECT … FOR UPDATE` added after
pre-entry check, before domain write |
| `execute_timeout_with_marker` | same |
| `execute_kick_with_marker` | same |
| `execute_delete_with_marker` | same |
| `record_failure` | wrapped in transaction; `SELECT … FOR UPDATE` +
clock check before state update |
### 3. Unused standalone counter helpers removed
`increment_reply_count`, `decrement_reply_count` (both in `thread.rs`),
and `Db::decrement_reply_count` have no production callers outside their
forwarding wrappers. Both perform unguarded autocommit writes that
bypass the deletion-transition/atomicity invariant. Removed to prevent
future misuse.
---------
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz>
Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz>
Adds a relay admin console under Settings — the single surface for
relay-level operator work — replacing the previously unreachable
moderation section. Operators authenticate with their own Nostr key over
NIP-98 — no browser extension, no bearer token — to view deployment-wide
moderation reports and product feedback, resolve/dismiss/escalate/reopen
reports, update feedback status, and manage the operator/moderator
staffing roster.
## Nav reachability
The old `moderation` section id was defined in `settingsSections` but
never wired into any group in `settingsNavGroups`, so the sidebar never
rendered it — unreachable since #1617. This PR replaces it with a
`relay-admin` section wired into the Communities nav group, pointing at
the relay admin console, and drops the separate `admin-console` section
id so a single surface owns relay-level trust & safety.
The Relay admin nav entry is always visible. Auth gates the panel
itself; the nav entry is a door, not a credential — hiding it behind
discovery state would strand an operator whose relay transiently fails
NIP-11 discovery with no path back to the connection settings.
## Discovery and connection
On mount the console reads the connected relay's NIP-11 document for the
optional `admin_api` field. When a valid origin is discovered **and its
host matches the connected relay's host** (case-insensitive, host
identity only), it is automatically saved and probed — the panel renders
immediately with no Save step required. A cross-host advertisement is
pre-fill only: it populates the manual origin field under Advanced and
is never saved or probed without an explicit Save, so a relay cannot
direct an unconsented NIP-98 signature at a third-party origin; residual
exposure on the same-host path is bounded by NIP-98's URL/method/payload
binding. Saving is only required for manual origin changes. The
advertised origin is untrusted input: revalidated through
`AdminOrigin::parse`, falling back to manual entry when absent or
invalid. A saved manual origin always takes precedence over discovery.
## Auth and transport (Rust, `src-tauri/src/commands/admin/`)
- `AdminOrigin` value object: validates scheme + host + optional port,
rejects credentials/path/query/fragment; `http://` only for loopback.
The relay side normalizes its configured admin host at config load and
compares inbound `Host`/`Origin` hosts case-insensitively.
- `AdminRoute` closed enum: no IPC surface accepts arbitrary URLs, so
the NIP-98-signed URL is byte-identical to the fetched URL.
- Dedicated no-redirect `reqwest` client as an SSRF guard: a relay `3xx`
is an error and the NIP-98 header never crosses origins.
- `admin_probe` signs `GET /probe` and returns a typed state
(`nip98Authorized` / `nip98Denied` / `disabled` / `notAdminApi` /
`networkOrIntercepted`). The response body is validated against the full
relay contract — `nip98Authorized` only when the complete NIP-98
invariant holds, `disabled` only on a coherent disabled-mode body; any
incoherent or unrelated JSON classifies as `notAdminApi`, so the console
never fails open at the network boundary. Unknown fields are tolerated
for forward compatibility.
- NIP-98 signing via `AppState::signing_keys()`, one retry on `401` with
a fresh signed event; response size bounded by a `Content-Length`
preflight and a streaming byte counter; per-pubkey origin storage with
atomic `0o600` writes.
## Relay admin console
The console is gated behind the relay `OPERATOR`/`MODERATOR` roles from
#3777; every `/api/admin/v1/*` route returns `403` to anyone else.
Community self-administration (`community-members` / Invites) and
in-channel enforcement (the 9040–9043 signed commands) are a separate
axis and are untouched. The previously-duplicate community report queue
(`ModerationQueueCard`, `moderationQueue.ts`, and three dead hooks) was
unreachable dead code and is deleted in its own commit;
`useBanMemberMutation` and the rest of `features/moderation/hooks.ts`
remain in use by the members sidebar and message menu.
## Console UI (TypeScript, `src/features/admin-console/`)
- `AdminConsoleSettingsCard`: discovery + probe flow, honest copy for
every probe state, manual origin under an `Advanced` disclosure at the
bottom. The role (operator/moderator) is rendered in the connection
status line as plain text ("Connected as operator") — no badge-shaped
elements above the tab row. The origin provenance (relay config /
database) appears inside the Advanced card as small muted text. Section
title changed to `Admin`.
- `AdminConsolePanel` with Reports / Feedback / Staffing tabs (Staffing
gated on `role === "operator"`); reports and feedback grouped by
community for cross-community triage.
- **Reports**: always requests `scope=all` so the existing
resolve/cancel/reopen controls can reach every status (`open`,
`processing`, `resolved`, `dismissed`, `escalated`). The relay's
omitted-scope default is `escalated`-only (the platform-safety
backstop); `scope=all` is explicit and scoped to this console. Full
action matrix per `target_kind` (event →
delete/kick/ban/timeout/dismiss/escalate; pubkey →
ban/timeout/dismiss/escalate; blob → dismiss/escalate); kick is
suppressed when the report carries no `channelId`. A `processing` row
stays navigable — enforcement state lives in the detail view. A `failed`
action (always pre-mutation) offers a single **Cancel & reopen** via
`POST /reports/{id}/cancel` with `{actionId}` fencing; there is no
client-side retry. `pending`/`enforcing` actions belong to the relay
recovery worker and offer no button; a `409` reloads detail. Lists
refetch on back-navigation after a mutation.
- **Report failure UX**: `reportErrorMessage()` strips 4xx/5xx status
prefixes and surfaces the relay's own error reason in the toast (e.g.
relay returns `"400: you cannot report this content"` → toast shows
`"you cannot report this content"`). Self-report blocking UI removed —
the relay has no self-report gate, and the failure was purely
client-side error surfacing.
- **Reason audience disclosure**: the Reason (optional) field shows
exact copy under the input based on selected action — Delete discloses
that reason is sent verbatim to the affected user and posted publicly in
the room; Kick/Ban/Timeout disclose affected-user only; Dismiss/Escalate
disclose reporter only. These mirror the actual relay notice paths.
- **Enforcement history**: the report detail carries the governing
action even after the report leaves `processing` — a report enforced
then reopened is `open` yet still shows its `succeeded` action as
executed history alongside the resolve form; a reopen does not un-happen
a ban. The resolve form gates on `open` status alone.
- **Reopen**: terminal reports (`resolved`/`dismissed`/`escalated`) can
be returned to `open` for re-triage via `POST /reports/{id}/reopen`.
Reopen never reverses applied enforcement, and the copy says so.
- **Feedback**: list, detail, and status control
(`new`/`reviewed`/`archived`) with a generation-fenced attachment
viewer. A purged source community severs provenance to `null` rather
than deleting the row; severed rows bucket under a "source community
removed" heading.
- **Staffing**: Add is create-only with display names resolved via
`useUsersBatchQuery` and npub cross-fade on hover
(`HoverStaffingIdentity`). An entered key that already appears in the
authoritative roster (config, owner-fallback, or DB) is rejected locally
with an inline duplicate-key message and no request is issued; a `409
Conflict` from add, role change, or remove surfaces the relay's parsed
error body via `adminErrorMessage(e)` — distinguishing config-backed key
conflicts from last-operator conflicts without HTTP-status inference.
Roster with `config`/`owner_fallback`/`db` source labels; config-backed
entries disable remove client-side. In-place role change via `<select>`
calling `putAdminOperator`; the relay responds with the effective
`OperatorEntry` (`pubkey`, `effectiveRole`, `sources`) in the same shape
as the roster list. Read-only badge for config-managed entries.
- **Timeout expiry**: `useTimeoutState` clears the store when derived
state is `INACTIVE` but the store is still active; the 1s tick is scoped
to entries with a known `expiresAtMs` and owned by
`ComposerTimeoutBanner` (mounted only while a timeout is active), while
`ChannelPane` subscribes to the boolean `useTimeoutActive()` — the pane
re-renders when a timeout starts or ends, not every second.
`useMembersSidebarModeration` ticks `nowMs` only while the sidebar is
open, the viewer can moderate, and some member has a future
`mutedUntil`; the tick after the last expiry stops the interval.
- Staffing refreshes the principal after a self-demotion or
self-removal: `AdminConsolePanel` passes `onSelfMutation` to
`StaffingTab`, which re-probes the saved origin so the role badge and
tab visibility update without a manual re-probe.
- Staffing mutation failures, including both 409 variants (config-backed
key vs. last operator), surface the relay's parsed error via
`adminErrorMessage`, so the last-operator recovery guidance is shown.
- Mutations confirm via `sonner` toasts; failures surface the relay's
parsed error `message`, not raw JSON. The `disabled` auth mode renders
read-only.
## Mutation idempotency
Resolve and reopen carry a per-attempt `requestId`. On first submit the
whole command (`{requestId, action, reason, expirationSecs}`) is frozen;
after an ambiguous failure (409, 5xx, transport error, truncated
response) the snapshot is retained, action/reason/duration controls are
locked, and the retry sends the exact same payload byte-for-byte. A
definitive pre-commit rejection (non-409 4xx with `bodyComplete: true`)
discards the snapshot, unlocks controls, and the corrected submit uses a
fresh payload. On success the toast derives from the authoritative
`AdminReportResolution` (`activeAction.action` when present; otherwise
`status` for decision-only outcomes) — never from the mutable form
selection.
The native mutation commands — including operator delete — reject with a
typed `AdminMutationError` carrying the relay's HTTP status
(`relayStatus`, `null` when no verdict exists) and a `bodyComplete` flag
that is `true` only when the full response body was read.
## Restriction routes contract change
`GET /members/restrictions` and `DELETE /members/{pubkey}/ban|timeout`
now take `communityHost` instead of `communityId`; the relay resolves
the tenant itself and returns `400 unknown_community_host` for an
unmapped host. This is a breaking contract change with no compatibility
shim: the relay must run this build before a desktop that uses it,
scripts sending `communityId` must switch, and rolling the relay back
breaks the desktop Restrictions UI. `docs/admin/README.md` documents the
three routes in the route inventory and carries the migration note.
Restriction calls also carry the relay the list was loaded from, and the
native side rejects a mismatch before building any URL.
## Hardening
- Saved admin origins are stored per pubkey and per relay host. The host
slug parses the relay URL, keeps the port-drop for DNS names, and
encodes IPv6 hosts canonically, so two IPv6 relays never share a file
and no IPv6 slug can match a DNS slug.
- NIP-11 admin discovery has its own 10s request deadline and reads
`/info` success and error bodies through the bounded reader with a 64
KiB cap (`Content-Length` is only a pre-check).
- `PUT /operators` builds its `OperatorEntry` response from the
validated body (`effectiveRole = role`, `sources = ["db"]`) instead of
re-reading the roster, so a concurrent change can't turn a committed
write into a `403`.
Related: #3777 (relay `OPERATOR`/`MODERATOR` role model + NIP-98 auth +
`admin_api` NIP-11 advertisement — provides the runtime and the
discovery field this console consumes)
Related:
[builderbot-platform-core-infrastructure#140](https://github.com/squareup/builderbot-platform-core-infrastructure/pull/140)
(prod admin ingress allowlist and NIP-98 rollout)
## Screenshots
Captured headless at `197f0ba0c` against the mock bridge (1280×720).
### Setup
**Origin setup — Advanced disclosure open, idle state**
**Authorized console — all three tabs**
### Reports
**Reports queue — open, processing, resolved across two relay groups**
**Open report detail — reporter, target, message snapshot, resolve
form**
**Processing report — PROCESSING/HARASSMENT, ban enforcing state**
**Resolve form — Delete selected, audience disclosure copy**
**Resolved report — enforcement history block**
### Feedback
**Feedback list — community grouping with status badges**
**Feedback detail — mutable status control (operator mode)**
**Feedback detail — passive status badge (read-only/disabled mode)**
### Staffing
**Staffing roster — config/owner\_fallback/db source labels**
**Add form — new pubkey filled, ready to submit**
**Duplicate rejection — inline error for existing principal**
---------
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <wpfleger@block.xyz>
Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
Signed-off-by: Alia <d32955ad69077062930cc46cfe2df30ca9aaf6f8e76422681265e9e9af704d78@buzz.block.builderlab.xyz>
Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
Co-authored-by: Alia <d32955ad69077062930cc46cfe2df30ca9aaf6f8e76422681265e9e9af704d78@buzz.block.builderlab.xyz>
Follow-up to #7806.
- **A retired sections manager never writes the shared prefs cache.**
`_persist()` now returns once the manager is disposed. That covers every
path a torn-down manager could take after an account or relay switch,
including a late OK restoring its submitted layout and the `dispose()`
flush's read-before-write merging a head. Before this change, both could
overwrite the successor's cache on the same pubkey key.
- **Coverage:**
- a retired late OK and a retired flush pre-read both leave the
successor's cache untouched
- an edit made while an OK is held still publishes after the OK is
released (`_lastPublishedStore` is built from the submitted store)
- a same-second losing head adopted after a local edit still converges
UI, cache and relay once our OK wins. The adopted layout's pending
debounce is deliberately left armed, because its republish is what
re-converges this race.
**Residual:** an edit made just before our own echo arrives can be
replaced by that echo. This is existing behaviour on main and on
desktop.
---------
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz>
## Why
Buzz server components need one typed feature-flag contract without
forcing the open-source build to depend on LaunchDarkly. A staging or
production relay must not be able to choose the wrong provider through
runtime configuration.
## What
- Adds typed boolean and signed `i64` flags with static, environment,
and compile-gated LaunchDarkly evaluators.
- Defines an executable relay artifact contract that compiles exactly
one provider.
- Rejects zero or multiple relay provider features at compile time.
- Runs the LaunchDarkly feature tests and the provider compile matrix in
the unit CI lane and fallback test script.
## How
`buzz-feature-flags` stays provider-neutral. The future relay
composition root will expose one build path per artifact feature:
`static-feature-flags`, `environment-feature-flags`, or
`launchdarkly-feature-flags`. Runtime configuration carries only
settings for the selected provider. It never carries a provider name,
fallback, or precedence rule.
The crate still has no relay consumer. A locked compile fixture proves
each singleton builds and every zero or multi-provider combination fails
until the relay adopts this contract.
This removes the proposed runtime `ProviderMode` and leaves one
provider, one construction path, and one evaluator per artifact.
## Risk
This PR still has no relay or app consumer, so it changes no
user-visible behavior. Risk is limited to the new feature-flag crate,
its compile contract, and its unit-test lane.
## Testing
An external Rust consumer at `30cf968bfe85e82980fda7e63f5bebe649ca939f`
exercised six environment-evaluator scenarios and 59 assertions. The
compile-time correction adds no live consumer to exercise manually.
## Bigger picture
When `buzz-relay` adopts this crate, its build manifests must map each
distribution to one provider feature. That consumer PR must verify live
Relay Proxy reachability, secret ingestion, lifecycle ownership, and
user-visible behavior.
Generated with Codex
---------
Signed-off-by: tornquist <tornquist@squareup.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
## Buzz Desktop release v0.5.25
- **Frozen main:** `797012ff01a6d499959b45ed2e56f7927c6a4d6b`
- **Reviewed candidate:** `c8f73213089cbd5a0f1e675d3193558280d46e10`
- **Previous desktop release:** `desktop-v0.5.24`
- **Proposed immutable tag:** `desktop-v0.5.25`
This PR may be **squash merged** after the Desktop Release Candidate
check and all protected-branch checks pass. Merging authorizes
publication of the exact reviewed candidate; later or unrelated changes
on `main` cannot alter it.
The checked-in changelog accounts for every non-merge commit in the
release range. The Desktop tag points to the reviewed candidate commit,
not the later squash commit. Publication remains bound to that immutable
candidate tag.
Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Release Automation <release-automation@users.noreply.github.com>
Switch every CI job that starts MinIO to the public
`ghcr.io/block/buzz-minio:latest` image published by #7869. Integration
jobs pull the image; image builds stay in the separate, path-filtered
publisher workflow.
- Apply the CI Compose override to both desktop integration shards,
backend integration, relay E2E, and mesh lifecycle, including
script-mediated Compose calls. Both the server and bucket initializer
use the Buzz image.
- Override both MinIO images in Helm's quickstart CI values, covering
the server, bucket initializer, and relay's wait-for-bucket init
container in the gated kind installation.
- Select integration and mesh checks when either Compose file changes,
with regression coverage using the real pinned `dorny/paths-filter`
action.
### Publication verified
#7869 is merged, and [the first main-branch
publication](https://github.com/block/buzz/actions/runs/36021389137/job/107706874954)
succeeded. An anonymous pull using an empty Docker configuration
returned the publisher's digest:
`sha256:b8470bbeafbf57b20c86cf63804682b714bdcfdbb517f3770247e321e623f48f`.
This PR is rebased onto main and ready for consumer integration checks.
### Validation
- Ran the repository's MinIO smoke script against the actual published
AMD64 image: healthy startup, bucket initialization, object
upload/read/delete, and rejection of anonymous reads all passed. Used
the rendered CI Compose services with isolated local ports and resource
names.
- Verified `mc` runs and writes its configuration as Helm's non-root
UID/GID 65532 with dropped capabilities and no privilege escalation.
- Helm 3.16.4 lint and quickstart rendering passed; all three rendered
MinIO container references use the Buzz image.
- All 14 CI selection cases and the required-context isolation check
passed. Mesh workflow passes actionlint; shared workflows pass with
shellcheck disabled for pre-existing findings.
- Fresh repository-wide review traced workflow and script consumers and
found no remaining CI image omissions. Full application integration
checks and a real kind installation have not been run locally.
---------
Signed-off-by: Tyler Longwell <tlongwell@squareup.com>
Mobile half of the sidebar stale-reader fix (desktop: #7805). It makes
the channel sections, sort, stars and mutes managers converge on the
latest relay head.
## Changes
- **Tie-break:** sections, stars and mutes compare `(created_at, id)`
with `id < cursor`, which matches the relay's `ORDER BY created_at DESC,
id ASC`. Sort already did this.
- **Coherent cursor:** `_publish()` records the signed event ID through
`SignedEventRelay.submit(onSigned:)` and advances
`(_lastRemoteCreatedAt, _lastRemoteEventId)` together. It only advances
when the pair is after the current cursor, so a newer head learned
during the await is kept. This applies to sections, stars and mutes.
- **Stars/mutes startup retry:** one serialized `_syncWithRelay()`
(`_syncInFlight`/`_syncAgain`) with 2s→30s backoff. It retries until the
history head is applied and the live subscription is settled. The
stars/mutes managers no longer re-subscribe on CLOSED:
`RelaySessionNotifier` owns retryable and rate-limited CLOSED, and a
terminal CLOSED is never re-sent. Reconnect works through session replay
and provider rebuild. Sections and sort keep their existing manager
CLOSED retry.
- **Stars/mutes durability:** storage `write()` returns the
`setString()` result. A decode or apply error, or a persist that returns
false or throws, fails the attempt. The accepted head only advances once
it is durable, so the same head is retried.
- **Stars/mutes pending fence:** each read snapshots `_localRevision`
and `_publishPending`. If a local edit or a publish happened while the
read was in flight, the result is discarded. Startup recovery retries
it; a resume read does not. Per-entry arbitration is unchanged.
- **Sections publish commits content with its cursor:** the submitted
blob is committed together with its cursor, so a same-second loser
applied during the OK wait can't strand the device. A local edit made
during the wait is kept.
- **Stars/mutes undecodable head:** an undecodable head is skipped
without holding startup open. Only a persist failure keeps the head
unapplied and retried.
- **Resume re-read:** all four providers listen to
`appLifecycleProvider`. On `resumed`, each manager runs one guarded
history read through its existing fetch/apply path. It is one-shot:
skipped when a local edit or publish is pending as it starts, not
retried on failure, and it starts no timers or poll loop. The result is
discarded if a mutation lands before it applies, and a disposed or
superseded manager (sort generation fence) never persists it.
## Residuals
- If the app stays in the foreground the whole time and a healthy socket
drops an EVENT, the missed head is picked up on the next resume or
reconnect.
- Sections: a live event can still overwrite a pending local edit. This
is pre-existing, and the resume read adds no new path to it.
- Sort: a greater remote timestamp wins, by policy.
- Stars/mutes: entries with equal `updatedAt` can still resolve
differently on different clients, under the existing merge policy.
- Stars/mutes: publish reads first and keeps the entry with the later
`updatedAt`, so a peer whose clock runs fast can override a pending
local entry. This rule already exists on main and matches desktop.
- Sections and sort persistence failures are pre-existing and not
redesigned here.
## Size
Production: 10 files, +495/−162. Tests: 3 files, +718. The new
`sidebar_sync_fixture.dart` runs over the real `RelaySessionNotifier`
seam and is shared by `channel_reader_recovery_test.dart`. Plus a
sections tie-break case.
---------
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz>
Upstream MinIO image pulls are blocking CI (#7867). Add a separate
publisher for `ghcr.io/block/buzz-minio:latest`, so the reusable image
can be bootstrapped before CI adopts it in #7870.
- Build the checksummed official MinIO/mc release binaries from #7868 on
a digest-pinned Alpine base.
- Build only when image/workflow/Compose inputs change or on manual
dispatch. PRs build and smoke-test; only `block/buzz` main can publish.
- Run the real Compose healthcheck and initializer, object
upload/read/delete, and anonymous-access denial before publishing
`latest` plus a unique `sha-<commit>-run-<id>-<attempt>` tag.
- Manual dispatch disables Docker's layer cache to refresh Alpine
packages. Normal image builds retain caching; each maintenance rebuild
keeps its own tag.
### Rollout
This PR contains only the publisher and opt-in Compose override. **It
does not switch ordinary CI consumers**, so its checks do not require
the unpublished image. This is a separate PR from adoption, as required
by Buzz's squash-only merge rules.
1. Merge this PR; its main-branch workflow builds, tests, and publishes
the image.
2. Make the `buzz-minio` GHCR package public and verify an anonymous
pull of `ghcr.io/block/buzz-minio:latest`. New GHCR packages default to
private.
3. Rebase draft #7870 onto current main, retarget it to main, run its
integration checks, and merge it to switch all MinIO-backed CI jobs to
the published image.
### Validation
- Updated hosted [MinIO image build and smoke
test](https://github.com/block/buzz/actions/runs/36018177877) passed at
`700ab6d5346b37a64c9defde0016dc65c98aa790`; publication correctly
skipped on the PR.
- Hosted [ordinary
CI](https://github.com/block/buzz/actions/runs/36018178123) passed at
the same head. Its actual Git comparison detected only the five
publisher files, all application path filters were false, and the
MinIO-dependent integration checks were correctly skipped. Synced
current main before this run to eliminate an earlier stale-base
comparison that included unrelated ACP changes.
- Actual five changed paths were passed through the repo's pinned
`dorny/paths-filter`: all application domains were false. All 12
existing path-selection cases and the required-context isolation
contract also passed.
- Publisher actionlint, smoke-script shellcheck, and commit/push hooks
passed.
- Fresh local rebuild of `700ab6d5346b37a64c9defde0016dc65c98aa790`
passed with `docker buildx build --no-cache --platform linux/amd64
--load`. Logs confirm new Alpine index fetches and package installation
rather than a cached install layer. The committed smoke script passed
under local AMD64 emulation using the current merged Compose services
with isolated resource names and no published ports: healthcheck,
initializer/private bucket, object upload/read/delete, and anonymous
HTTP 403. Temporary containers, network, and volume were removed. Both
pinned binary checksums match the official release SHA-256 files.
- Full `just ci` was previously attempted: workspace formatting/Clippy,
desktop checks, and Tauri formatting passed; the run was stopped during
Tauri Clippy. No full local application-suite pass is claimed; hosted
application suites correctly skip this publisher-only change.
---------
Signed-off-by: Tyler Longwell <tlongwell@squareup.com>
