Files
Toju/toju-app/src/app/domains/server-directory/README.md
Myx bc2fa7de22 fix: multiple bug fixes
isolated users, db backup, weird disconnect issues for long voice sessions,
2026-04-26 22:54:13 +02:00

11 KiB

Server Directory Domain

Manages the list of server endpoints the client can connect to, health-checking them, resolving API URLs, and providing server CRUD, search, invites, and moderation. This is the central domain that other domains (auth, chat, attachment) depend on for knowing where the backend is.

Module map

server-directory/
├── application/
│   ├── facades/
│   │   └── server-directory.facade.ts           Thin domain boundary, delegates to ServerDirectoryService
│   └── services/
│       ├── server-directory.service.ts          Orchestrator: server CRUD, search, health, invites, moderation
│       └── server-endpoint-state.service.ts     Signal-based endpoint list, reconciliation with defaults, localStorage persistence
│
├── domain/
│   ├── constants/
│   │   └── server-directory.constants.ts        CLIENT_UPDATE_REQUIRED_MESSAGE
│   ├── logic/
│   │   ├── room-signal-source.logic.ts          Room → signal-source selector resolution
│   │   ├── room-signal-source.logic.spec.ts     Unit tests
│   │   └── server-endpoint-defaults.logic.ts    Default endpoint templates, URL sanitisation, reconciliation helpers
│   └── models/
│       └── server-directory.model.ts            ServerEndpoint, ServerInfo, ServerJoinAccessResponse, invite/ban/kick types
│
├── infrastructure/
│   ├── constants/
│   │   └── server-directory.infrastructure.constants.ts  Health-check timeout, localStorage keys
│   └── services/
│       ├── server-directory-api.service.ts            HTTP client for all server API calls
│       ├── server-endpoint-compatibility.service.ts   Semantic version comparison for client/server compatibility
│       ├── server-endpoint-health.service.ts          Health probe (GET /api/health with 5 s timeout, fallback to /api/servers)
│       └── server-endpoint-storage.service.ts         localStorage read/write for endpoint list and removed-default tracking
│
├── feature/
│   ├── invite/                              Invite creation and resolution UI
│   ├── server-search/                       Server search/browse panel
│   └── settings/                            Server endpoint management settings
│
└── index.ts                                 Barrel exports

Layer composition

The facade is a thin pass-through that delegates to ServerDirectoryService. The service delegates HTTP work to the API service and endpoint state to the state service. Health probing combines the health service and compatibility service. Storage is accessed only through the state service.

graph TD
    Facade[ServerDirectoryFacade]
    Service[ServerDirectoryService]
    State[ServerEndpointStateService]
    API[ServerDirectoryApiService]
    Health[ServerEndpointHealthService]
    Compat[ServerEndpointCompatibilityService]
    Storage[ServerEndpointStorageService]
    Defaults[server-endpoint-defaults.logic]
    Models[server-directory.model]

    Facade --> Service
    Service --> API
    Service --> State
    Service --> Health
    Service --> Compat
    API --> State
    State --> Storage
    State --> Defaults
    Health --> Compat

    click Facade "application/facades/server-directory.facade.ts" "Thin domain boundary" _blank
    click Service "application/services/server-directory.service.ts" "Orchestrator" _blank
    click State "application/services/server-endpoint-state.service.ts" "Signal-based endpoint state" _blank
    click API "infrastructure/services/server-directory-api.service.ts" "HTTP client for server API" _blank
    click Health "infrastructure/services/server-endpoint-health.service.ts" "Health probe" _blank
    click Compat "infrastructure/services/server-endpoint-compatibility.service.ts" "Version compatibility" _blank
    click Storage "infrastructure/services/server-endpoint-storage.service.ts" "localStorage persistence" _blank
    click Defaults "domain/logic/server-endpoint-defaults.logic.ts" "Default endpoint templates" _blank
    click Models "domain/models/server-directory.model.ts" "Domain types" _blank

Endpoint lifecycle

On startup, ServerEndpointStateService loads endpoints from localStorage, reconciles them with the configured defaults from the environment, and ensures at least one endpoint is active. Configured default endpoints are treated as active by default unless the user explicitly disabled or removed them.

stateDiagram-v2
    [*] --> Load: constructor
    Load --> HasStored: localStorage has endpoints
    Load --> InitDefaults: no stored endpoints
    InitDefaults --> Ready: save default endpoints
    HasStored --> Reconcile: compare stored vs defaults
    Reconcile --> Ready: merge, ensure active
    Ready --> HealthCheck: facade.testAllServers()

    state HealthCheck {
        [*] --> Probing
        Probing --> Online: /api/health 200 OK
        Probing --> Incompatible: version mismatch
        Probing --> Offline: request failed
    }

Health probing

The facade exposes testServer(endpointId) and testAllServers(). Both delegate through the service to ServerEndpointHealthService.probeEndpoint(), which:

  1. Sends GET /api/health with a 5-second timeout
  2. Reads the response's serverVersion and stable serverInstanceId
  3. Checks the reported version against the client version via ServerEndpointCompatibilityService
  4. If versions are incompatible, the endpoint is marked incompatible and deactivated
  5. If /api/health fails, falls back to GET /api/servers as a basic liveness check
  6. Updates the endpoint's status, latency, and version info in the state service

serverInstanceId lets the client detect when multiple configured URLs point at the same backend. ServerEndpointStateService.resolveCanonicalEndpoint() prefers one canonical endpoint per backend instance so REST calls, WebSocket routing, and room fallback logic do not treat same-instance aliases as different signaling clusters.

Room signaling now waits for that initial health sweep before the first saved-room reconnect attempt. That avoids a cold-start race where alias endpoints could open separate WebSocket managers before serverInstanceId had been learned.

sequenceDiagram
    participant Facade
    participant Health as HealthService
    participant Compat as CompatibilityService
    participant API as Server

    Facade->>Health: probeEndpoint(endpoint, clientVersion)
    Health->>API: GET /api/health (5s timeout)

    alt 200 OK
        API-->>Health: { serverVersion, serverInstanceId }
        Health->>Compat: evaluateServerVersion(serverVersion, clientVersion)
        Compat-->>Health: { isCompatible, serverVersion }
        Health-->>Facade: online / incompatible + latency + versions
    else Request failed
        Health->>API: GET /api/servers (fallback)
        alt 200 OK
            API-->>Health: servers list
            Health-->>Facade: online + latency
        else Also failed
            Health-->>Facade: offline
        end
    end

    Facade->>Facade: updateServerStatus(id, status, latency, versions)

The facade's searchServers(query) method supports two modes controlled by a searchAllServers flag:

  • Single endpoint: searches only the active server's API
  • All endpoints: fans out the query to every online active endpoint via forkJoin, then deduplicates results by server ID

The API service normalises every ServerInfo response, filling in sourceId, sourceName, and sourceUrl so the UI knows which endpoint each server came from.

That search fan-out is discovery only. Once a room is created or joined, the room keeps an authoritative signal-server affinity via its sourceId / sourceUrl. The join response can repair stale saved metadata, and reconnect logic now retries that authoritative endpoint first before probing any other configured endpoints.

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.

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.

The renderer may cache room data locally, but channel creation, rename, and removal must round-trip through the server-directory API instead of being treated as client-only state. Server-side normalisation deduplicates channel names within each channel type, so a text general channel and a voice General channel can coexist while duplicate voice-to-voice or text-to-text names are still rejected.

Default endpoint management

Default servers are configured in the environment file. The state service builds DefaultEndpointTemplate objects from the configuration and uses them during reconciliation:

  • Stored endpoints are matched to defaults by defaultKey or URL
  • Missing defaults are added unless the user explicitly removed them (tracked in a separate localStorage key)
  • Default endpoints stay active by default unless the user explicitly disabled them (tracked separately from the endpoint payload)
  • restoreDefaultServers() re-adds any removed defaults and clears the removal tracking
  • The primary default URL is used as a fallback when no endpoint is resolved

Saved rooms can also self-heal their endpoint metadata. If a room has missing or stale source information, the client now searches the configured endpoints for that room, restores the correct source mapping, and persists the repair locally.

URL sanitisation strips trailing slashes and /api suffixes. Protocol-less URLs get http or https based on the current page protocol.

Server administration

The facade provides methods for server registration, updates, and unregistration. These map directly to the API service's HTTP calls:

Method HTTP Endpoint
registerServer POST /api/servers
updateServer PUT /api/servers/:id
unregisterServer DELETE /api/servers/:id

Invites and moderation

Method Purpose
createInvite(serverId, request) Creates a time-limited invite link
getInvite(inviteId) Resolves invite metadata
requestServerAccess(request) Joins a server (via membership, password, invite, or public access)
kickServerMember(serverId, request) Removes a user from the server
banServerMember(serverId, request) Bans a user with optional reason and expiry
unbanServerMember(serverId, request) Lifts a ban

Persistence

All endpoint state is persisted to localStorage under two keys:

Key Contents
metoyou_server_endpoints Full ServerEndpoint[] array
metoyou_removed_default_server_keys Set of default endpoint keys the user explicitly removed

The storage service handles JSON serialisation and defensive parsing. Invalid data falls back to empty state rather than throwing.