feat(relay): make per-owner community limit configurable via BUZZ_MAX_COMMUNITIES_PER_OWNER#2599
Merged
tlongwell-block merged 1 commit intoJul 25, 2026
Conversation
Multi-tenant deployments (one relay serving many communities behind host-based tenancy) routinely need more than three communities per operator identity, but MAX_COMMUNITIES_PER_OWNER is a hardcoded const. The provisioning surface then rejects new communities with limit_reached, which downstream UIs tend to surface as a confusing "subdomain already taken". Introduce BUZZ_MAX_COMMUNITIES_PER_OWNER: read once per process, must be a positive integer, anything else falls back to the stock default of 3 so existing deployments are unaffected. Enforcement stays in the authoritative relay-layer checks (provision + transfer), unchanged. The parse/fallback rules live in a pure helper with unit tests; the cached getter stays trivial. Signed-off-by: Lee Salminen <leesalminen@gmail.com>
leesalminen
force-pushed
the
feat/configurable-owner-community-limit
branch
from
July 25, 2026 11:46
c5d8295 to
da03945
Compare
tlongwell-block
approved these changes
Jul 25, 2026
tlongwell-block
enabled auto-merge (squash)
July 25, 2026 13:22
Collaborator
|
Thanks for the contribution, @leesalminen 👋 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_OWNERis currently a hardcoded const, and hitting it surfaces as alimit_reached409 fromPOST /operator/communities— which provisioning UIs tend to mislabel (mine reported it as "subdomain already taken").This makes the limit configurable per deployment:
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.create_community_with_owner) and ownership transfer (inside the advisory-lock transaction).effective_owner_limit) with unit tests, keeping the cached getter trivial.Test plan
cargo test -p buzz-db --lib— newowner_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 test(buzz-db): replica_fence unit test fails on Linux due to sub-microsecond Utc::now() precision #2369.)cargo clippy -p buzz-db --all-targetsandcargo fmtclean.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