fix(relay): distinguish transient tenant-bind failures from unmapped hosts (#5030) - #5036
Open
yippietheproducer wants to merge 1 commit into
Open
fix(relay): distinguish transient tenant-bind failures from unmapped hosts (#5030)#5036yippietheproducer wants to merge 1 commit into
yippietheproducer wants to merge 1 commit into
Conversation
…hosts (block#5030) The WS door and HTTP bridge collapsed every tenant-bind failure to 404 ("relay: no community is configured for this host"). A DB hiccup during a reconnect therefore looked identical to a decommissioned relay, and clients that classify 404 as terminal (buzz-acp: `WebSocket(Http): 404 -> terminal`) gave up on healthy relays. block#5030 measured a 22% reconnect-failure rate on hosted communities with sessions going dark once the 5-attempt budget was exhausted. bind_community now maps BindError to a status: UnmappedHost -> 404 (permanent, clients stop retrying), Lookup -> 503 (transient, clients retry 5xx). The rejection BODY stays byte-identical for both variants (never echo the host, never leak the underlying error), preserving the anti-enumeration property in the steady state; the only new signal is the status code, observable solely while the backend lookup is actually failing. Applies to every bind site: WS door (router.rs), audio handler, and the four HTTP bridge endpoints. Covered by tenant unit tests asserting the status split and the identical bodies. Signed-off-by: mmaciejek <chacinskimaciej@gmail.com>
yippietheproducer
force-pushed
the
pr/5030-bind-status
branch
from
August 6, 2026 10:17
f023042 to
487a9bc
Compare
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
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.
Fixes #5030 (the relay-generated half).
Problem
The WS door and every HTTP bridge endpoint collapsed all tenant-bind
failures to
404 "relay: no community is configured for this host". A DBhiccup during a reconnect therefore looked identical to a decommissioned
relay, and clients that classify 404 as terminal (
buzz-acp:WebSocket(Http): 404 → terminal) gave up on healthy relays. #5030measured a 22% reconnect-failure rate on hosted communities with agent
sessions going dark once the 5-attempt budget was exhausted.
Fix
bind_communitynow mapsBindErrorto a status viaBindError::http_status():UnmappedHost→ 404 (permanent — clients correctly stop retrying)Lookup→ 503 (transient — clients retry 5xx; buzz-acp alreadyclassifies
429 | 502 | 503 | 504as transient)The rejection body stays byte-identical for both variants — never echo
the host, never leak the underlying error — preserving the anti-enumeration
property in the steady state. The only new signal is the status code, and
it is observable solely while the backend lookup is actually failing (the
narrow, documented tradeoff; the alternative made healthy relays
indistinguishable from decommissioned ones to every client).
Applied at every bind site: WS door (
router.rs), audio handler, andthe four HTTP bridge endpoints (
submit_event,query_events,count_events, workflow).Notes
error: internal error checking restriction stateon the auth path — is the ban-check failingclosed on a DB error, which is correct fail-closed behavior, and
buzz-acpalready treatserror:-prefixed auth failures as transient(
is_terminal_auth_failure). No change needed there.Verification
cargo check -p buzz-relay— clean, zero warningsboth variants share an identical, error-free body
buzz-relaylib suite: 848 passed / 1 failed — the failure(
api::mesh_demo::demo_join_forwarded_arm_round_trips_echo) is apre-existing timing flake, reproduced on the clean tree without this
change