fix: recurriing network issue
All checks were successful
Queue Release Build / prepare (push) Successful in 18s
Deploy Web Apps / deploy (push) Successful in 6m32s
Queue Release Build / build-windows (push) Successful in 26m8s
Queue Release Build / build-linux (push) Successful in 40m18s
Queue Release Build / finalize (push) Successful in 42s

This commit is contained in:
2026-04-30 04:04:34 +02:00
parent b1fe286be8
commit a49e18b9f0
16 changed files with 522 additions and 17 deletions

View File

@@ -157,6 +157,10 @@ The `/search` My Servers row and the server rail both read from the active user'
Fallback stays temporary. If the authoritative endpoint is unavailable, the client can probe other active compatible endpoints as a last resort for the current session, but it does not rewrite the room's saved affinity to that fallback endpoint.
Be careful around endpoint failure semantics. `ensureEndpointVersionCompatibility()` returns `false` for both incompatible versions and unreachable/offline endpoints. Only an endpoint with `status === 'incompatible'` should stop the fallback cascade with the update-required message. Cloudflare `521`/`522`, network timeouts, and WebSocket `1006` failures must continue to the next active compatible endpoint.
`ServerDirectoryApiService.getServer()` also returns `null` for both authoritative `SERVER_NOT_FOUND` and retryable endpoint failures. Callers that need recovery must search active endpoints before treating `null` as proof that a saved room is gone or its source is stale.
## Server-owned room metadata
`ServerInfo` also carries the server-owned `channels` list for each room. Register and update calls persist this channel metadata on the server, and search or hydration responses return the normalised channel list so text and voice channel topology survives reloads, reconnects, and fresh joins.