mirror of
https://github.com/block/buzz.git
synced 2026-08-18 06:50:31 +02:00
Lee SalminenandGitHub
2a051a404d
Closes #2600 ## Summary Self-hosted multi-tenant deployments (one relay serving many communities via host-based tenancy) routinely need more than three communities owned by the same operator identity. `MAX_COMMUNITIES_PER_OWNER` is currently a hardcoded const, and hitting it surfaces as a `limit_reached` 409 from `POST /operator/communities` — which provisioning UIs tend to mislabel (mine reported it as "subdomain already taken"). This makes the limit configurable per deployment: - New env var `BUZZ_MAX_COMMUNITIES_PER_OWNER` — read once per process, must parse as a positive integer; missing/invalid/non-positive values fall back to the existing default of **3**, so current deployments are unaffected. - Enforcement locations are unchanged and stay in the authoritative relay-layer checks: community provisioning (`create_community_with_owner`) and ownership transfer (inside the advisory-lock transaction). - Parse/fallback rules are extracted into a pure helper (`effective_owner_limit`) with unit tests, keeping the cached getter trivial. ## Test plan - `cargo test -p buzz-db --lib` — new `owner_limit_*` tests cover default, invalid, non-positive, and positive-override cases. (Pre-existing unrelated failure on clean main: `replica_fence::tests::fence_starts_closed_and_opens_on_advance`, tracked in #2369.) - `cargo clippy -p buzz-db --all-targets` and `cargo fmt` clean. - Deployed on my multi-tenant relay (vibecode.casa) with `BUZZ_MAX_COMMUNITIES_PER_OWNER=100`: provisioning a 4th community for the same owner succeeds; without the var the stock limit of 3 still applies. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: Lee Salminen <leesalminen@gmail.com>