release: версия 0.0.31

Silent-refresh считал неудачей любой не-2xx ответ и на каждую такую
неудачу сбрасывал access-токен с редиректом на /login. Ответ 500 — это
«серверу плохо», а не «вы не авторизованы»: 07.08.2026 refresh отвечал
500 из-за исчерпанного пула БД, и фронтенд разлогинивал людей посреди
работы, а повторный вход падал тем же 500.

`refreshAccessToken` теперь различает причины: `invalid` (backend отверг
сессию — 4xx, единственный случай для разлогина), `unavailable` (5xx,
таймаут, обрыв сети — сессия цела, токен сохраняется, пользователь
получает обычную ошибку запроса) и `ok`. Восстановление сессии при
старте приложения на `unavailable` повторяет попытку трижды с задержками
1/2/4 с, вместо того чтобы сразу объявить пользователя неавторизованным.

.env.example

@@ -104,6 +104,12 @@ UVICORN_WORKERS=2
 DB_POOL_SIZE=10
 DB_MAX_OVERFLOW=10
 DB_POOL_TIMEOUT=10
+# Пул соединений с Redis НА КАЖДЫЙ воркер. Считается по УЧАСТНИКАМ, а не по
+# запросам: WS-подключение комнаты держит собственную pub/sub-подписку всё
+# время, пока человек в конференции. Дефолт redis-py (100) упирался в потолок
+# примерно на сотом одновременном участнике на воркер. Сверху ограничивает
+# maxclients самого Redis (по умолчанию 10000) — на все процессы разом.
+REDIS_MAX_CONNECTIONS=500
 
 # --- Email (рассылка саммари + .ics-приглашения) ---
 # `console` — дефолт для dev (письмо только логируется, ссылка подтверждения
@@ -122,7 +128,7 @@ SMTP_TIMEOUT_S=30
 # --- Версия инстанса (релиз v0.0.1) ---
 # install.sh копирует значение из корневого файла VERSION при каждой
 # установке/обновлении — руками менять не нужно.
-VIDCONF_VERSION=0.0.30
+VIDCONF_VERSION=0.0.31
 
 # --- Профили compose. Дефолт ниже (`media,monitoring`) — только для ручного
 # `docker compose up` БЕЗ install.sh: медиа (LiveKit+coturn) + мониторинг,

CHANGELOG.md

@@ -3,6 +3,43 @@
 Формат основан на [Keep a Changelog](https://keepachangelog.com/ru/1.1.0/),
 проект придерживается [семантического версионирования](https://semver.org/lang/ru/).
 
+## [0.0.31] — 2026-08-09
+
+Разбор провала входа на нагрузочном тесте 07.08.2026: комната держала
+соединения с БД и Redis на каждого участника.
+
+### Исправлено
+- **Вход в систему переставал работать, когда в конференции набиралось
+  около сорока человек.** WS-подключение комнаты (чат и очередь рук)
+  держало занятым одно соединение с БД всё время, пока участник сидел
+  в конференции: SELECT'ы хендшейка открывали транзакцию, а закрыть её
+  было некому. Пул — 20 соединений на воркер (40 на инстанс), поэтому
+  сороковой вошедший выгребал его досуха, и все остальные запросы —
+  резолв конференции, гостевой вход, логин, обновление токена — начинали
+  отвечать 500. Теперь соединение возвращается в пул сразу после
+  хендшейка; на локальном стенде 120 участников на одном воркере не
+  занимают ни одного соединения в простое (было: 20 из 20 при 20
+  участниках, дальше вход не работал вовсе).
+- **Пользователя выкидывало из системы, когда серверу было плохо.**
+  Фоновое обновление access-токена считало неудачей любой отрицательный
+  ответ и на каждую такую неудачу сбрасывало сессию с переходом на
+  страницу входа. Ответ 5xx (и обрыв сети) теперь означает «сервер
+  временно недоступен»: сессия сохраняется, пользователь остаётся
+  в системе и получает обычную ошибку запроса. Разлогинивание осталось
+  только там, где backend прямо сказал, что сессия недействительна.
+  Восстановление сессии при старте приложения повторяет попытку трижды,
+  прежде чем показать страницу входа.
+
+### Технические детали
+- Размер пула соединений с Redis задан явно (`REDIS_MAX_CONNECTIONS`,
+  по умолчанию 500): на нём висят долгоживущие pub/sub-подписки комнаты —
+  по одной на участника, — а дефолт redis-py 8 (100) упирался в потолок
+  примерно на сотом участнике на воркер. Второй потолок того же рода,
+  что и пул БД; найден при проверке правки выше на 120 участниках.
+- Размеры пулов БД (`DB_POOL_SIZE`/`DB_MAX_OVERFLOW`) не менялись
+  осознанно: соединение больше не удерживается впустую, поэтому
+  расширение пула лечило бы симптом и лишь отодвинуло порог.
+
 ## [0.0.30] — 2026-08-04
 
 Согласие на обработку персональных данных при регистрации + отключаемый модуль.

VERSION

@@ -1 +1 @@
-0.0.30
+0.0.31

backend/api/chat.py

@@ -87,6 +87,26 @@ async def chat_websocket(
     await pubsub.subscribe(channel, room_channel)
     try:
         history = await service.history(conference)
+        # 🔑 Вернуть соединение с БД в пул ДО входа в долгоживущие насосы.
+        #
+        # Хендшейк выше сделал несколько SELECT'ов (тоггл чата, конференция,
+        # тоггл рук, история) — SQLAlchemy открыла транзакцию на первом же из
+        # них и держала бы её, а с ней и соединение из пула, ВСЁ время жизни
+        # WS: участник сидит в комнате час — час занято соединение. Пул это
+        # `db_pool_size + db_max_overflow` на воркер (10 + 10), то есть
+        # 40 на инстанс из двух воркеров, и сороковой вошедший выгребал его
+        # досуха: `pg_stat_activity` показывал 40 соединений
+        # `idle in transaction` при одном `active`, а посторонние ручки
+        # (резолв, гостевой вход, логин, refresh) начинали падать в
+        # `QueuePool limit ... timed out` и отдавать 500. Ровно это положило
+        # вход на нагрузочном тесте 07.08.2026 при ~50 участниках.
+        #
+        # Соединение здесь больше не нужно: оба насоса ниже работают через
+        # Redis, а единственная запись в БД (`persist_and_publish`) сама
+        # открывает транзакцию и коммитит её, освобождая соединение сразу.
+        # ⚠️ Любое чтение из БД, добавленное между этой строкой и концом
+        # обработчика, обязано так же завершаться commit/rollback.
+        await session.commit()
         await websocket.send_json(ChatHistoryOut(messages=history).model_dump(mode="json"))
         seen_ids = {item.id for item in history}
 

backend/core/config.py

@@ -38,6 +38,20 @@ class Settings(BaseSettings):
     # и показывает проблему, а не висит полминуты, делая вид, что всё живо.
     db_pool_timeout: int = 10
 
+    # --- Пул соединений с Redis ---
+    # Считается по УЧАСТНИКАМ, а не по запросам: каждое WS-подключение комнаты
+    # (`api/chat.py`) держит собственное pub/sub-соединение всё время, пока
+    # человек сидит в конференции, — и берёт его из этого же пула, что и
+    # обычные команды. redis-py 8 поставил дефолт `max_connections=100`
+    # (раньше предел был условно бесконечным), поэтому сотый участник на
+    # воркер выгребал пул досуха и WS падал уже на `hgetall` очереди рук —
+    # воспроизведено локально при 99 одновременных подключениях.
+    # 500 — с запасом на инстанс, рассчитанный на пару сотен участников
+    # на воркер; соединения создаются по мере надобности, само по себе
+    # значение ничего не стоит. Потолок сверху — `maxclients` у Redis
+    # (дефолт 10000) на ВСЕ процессы вместе, включая Celery-воркеры.
+    redis_max_connections: int = 500
+
     # --- Версия инстанса (релиз v0.0.1) ---
     # install.sh копирует значение из файла `VERSION` (корень репозитория) в
     # `.env` при каждой установке/обновлении — здесь только чтение готового

backend/core/redis.py

@@ -6,4 +6,11 @@ from core.config import get_settings
 
 settings = get_settings()
 
-redis_client: Redis = Redis.from_url(settings.redis_url, decode_responses=True)
+redis_client: Redis = Redis.from_url(
+    settings.redis_url,
+    decode_responses=True,
+    # Размер пула задаём явно: дефолт redis-py (100) рассчитан на команды, а у
+    # нас на нём же висят долгоживущие pub/sub-подписки комнаты — по одной на
+    # участника (см. `core/config.py`, `redis_max_connections`).
+    max_connections=settings.redis_max_connections,
+)

backend/tests/test_chat_ws.py

@@ -237,6 +237,42 @@ async def test_no_duplicate_when_message_already_in_history(
     assert received["message"]["text"] == "genuinely new"
 
 
+# --- Удержание соединения с БД ------------------------------------------------
+
+
+async def test_handshake_releases_db_connection(
+    db_session: AsyncSession, ws_client: WSFactory
+) -> None:
+    """Regression: после хендшейка WS не держит открытую транзакцию БД.
+
+    Обработчик получает `AsyncSession` на ВСЁ время жизни соединения, а
+    SELECT'ы хендшейка (тоггл чата, конференция, тоггл рук, история)
+    открывают транзакцию. Без явного `commit` она висела бы, пока участник
+    сидит в комнате: одно занятое соединение из пула на каждого человека
+    в конференции. На нагрузочном тесте 07.08.2026 это выгребло пул
+    (`db_pool_size + db_max_overflow` = 20 на воркер, 40 на инстанс) при
+    сорока участниках — и вход в систему начал отдавать 500 всем
+    остальным. Проверяем именно отсутствие открытой транзакции, а не
+    состояние пула: тестовая сессия привязана к своему соединению
+    (см. докстринг `tests/conftest.py`) и пул не задействует.
+    """
+    conference = await _make_conference(db_session)
+    user = await _make_user(db_session)
+    await db_session.commit()
+
+    ws = ws_client(_chat_path(conference.id))
+    await _connect_and_auth(ws, _user_token(conference, user))
+
+    assert not db_session.in_transaction()
+
+    # Запись сообщения открывает транзакцию заново — и тоже обязана её
+    # закрыть, иначе первый же чат вернул бы прежнее поведение.
+    await ws.send_json({"type": "message", "text": "проверка"})
+    echo = await ws.receive_json()
+    assert echo["type"] == "message"
+    assert not db_session.in_transaction()
+
+
 # --- Auth: коды закрытия ----------------------------------------------------
 
 

deploy/docker-compose.yml

@@ -89,7 +89,7 @@ services:
       MEDIA_ROOT: ${MEDIA_ROOT:-/app/media}
       # Версия инстанса (релиз v0.0.1) — install.sh копирует значение
       # из файла VERSION (корень репозитория) в .env; отдаётся в GET /api/health.
-      VIDCONF_VERSION: ${VIDCONF_VERSION:-0.0.30}
+      VIDCONF_VERSION: ${VIDCONF_VERSION:-0.0.31}
       # Число процессов uvicorn (см. backend/Dockerfile). Дефолт 2 рассчитан
       # на 4-ядерный сервер, где ядра делятся с LiveKit. Поднимая значение,
       # проверьте бюджет соединений с БД: каждый воркер держит свой пул

frontend/src/api/client.ts

@@ -4,8 +4,15 @@
  * - Access-токен подставляется из authStore (память, не localStorage).
  * - На 401 выполняется один silent-refresh (POST /auth/refresh,
  *   credentials: 'include' — сессия читается из httpOnly-cookie) и повтор
- *   исходного запроса. Если refresh не удался — access-токен сбрасывается и
- *   выполняется редирект на /login.
+ *   исходного запроса.
+ * - ⚠️ Причина неудачи refresh различается (`RefreshOutcome`). Сессия
+ *   сбрасывается ТОЛЬКО когда backend сказал, что она недействительна
+ *   (`invalid`). Ответ 5xx или обрыв сети — это «серверу плохо», а не «вы не
+ *   авторизованы»: токен сохраняется, пользователь остаётся в системе и
+ *   получает обычную ошибку запроса. Раньше различия не было, и на
+ *   нагрузочном тесте 07.08.2026 (когда refresh отвечал 500 из-за
+ *   исчерпанного пула БД) фронтенд разлогинивал людей посреди работы, а
+ *   повторный вход падал тем же 500.
  * - Параллельные 401 схлопываются в один refresh-запрос (refreshPromise).
  */
 import { authStore } from '@/auth/authStore'
@@ -44,26 +51,48 @@ interface RequestOptions extends Omit<RequestInit, 'body'> {
   skipAuthRefresh?: boolean
 }
 
-let refreshPromise: Promise<boolean> | null = null
+/**
+ * Итог silent-refresh.
+ *
+ * - `ok` — выдан новый access-токен;
+ * - `invalid` — backend отверг refresh-сессию (просрочена, отозвана, reuse):
+ *   единственный случай, когда пользователя правда надо разлогинить;
+ * - `unavailable` — до ответа «сессия недействительна» дело не дошло: 5xx,
+ *   таймаут или обрыв сети. Сессия при этом цела, `status` — HTTP-код
+ *   ответа или `null`, если запрос не доехал вовсе.
+ */
+export type RefreshOutcome =
+  | { result: 'ok' }
+  | { result: 'invalid' }
+  | { result: 'unavailable'; status: number | null }
+
+let refreshPromise: Promise<RefreshOutcome> | null = null
 
 /**
  * Выполняет silent-refresh access-токена через httpOnly refresh-cookie.
- * Возвращает true при успехе. Параллельные вызовы переиспользуют один запрос.
+ * Параллельные вызовы переиспользуют один запрос.
  */
-export async function refreshAccessToken(): Promise<boolean> {
+export async function refreshAccessToken(): Promise<RefreshOutcome> {
   if (!refreshPromise) {
-    refreshPromise = (async () => {
+    refreshPromise = (async (): Promise<RefreshOutcome> => {
       try {
         const response = await fetch(`${API_BASE}/auth/refresh`, {
           method: 'POST',
           credentials: 'include',
         })
-        if (!response.ok) return false
+        if (response.ok) {
           const data = (await response.json()) as { access_token: string }
           authStore.setAccessToken(data.access_token)
-        return true
+          return { result: 'ok' }
+        }
+        // Про недействительность сессии backend говорит только кодом 4xx.
+        // Всё остальное (500/502/503/504) — состояние сервера, а не сессии.
+        return response.status >= 500
+          ? { result: 'unavailable', status: response.status }
+          : { result: 'invalid' }
       } catch {
-        return false
+        // Сеть не доехала — про сессию мы так ничего и не узнали.
+        return { result: 'unavailable', status: null }
       } finally {
         refreshPromise = null
       }
@@ -124,9 +153,17 @@ export async function apiRequest<T = unknown>(path: string, options: RequestOpti
   let response = await doFetch()
 
   if (response.status === 401 && !skipAuthRefresh) {
-    const refreshed = await refreshAccessToken()
-    if (refreshed) {
+    const outcome = await refreshAccessToken()
+    if (outcome.result === 'ok') {
       response = await doFetch()
+    } else if (outcome.result === 'unavailable') {
+      // Серверу плохо — сессию не трогаем и на /login не выкидываем:
+      // как только backend оживёт, следующий запрос обновит токен сам.
+      throw new ApiError(
+        outcome.status ?? 0,
+        null,
+        'Сервер временно недоступен. Попробуйте ещё раз через минуту.',
+      )
     } else {
       redirectToLogin()
       throw new ApiError(401, null, 'Сессия истекла')

frontend/src/auth/AuthProvider.tsx

@@ -4,6 +4,20 @@ import { authStore } from '@/auth/authStore'
 import { refreshAccessToken } from '@/api/client'
 import { AuthContext, type AuthContextValue, type AuthStatus } from '@/auth/authContext'
 
+/**
+ * Задержки повторов восстановления сессии, если backend отвечает 5xx.
+ *
+ * Недоступность сервера — не повод объявлять пользователя неавторизованным:
+ * refresh-cookie цела, и через несколько секунд сессия обычно поднимается
+ * сама. Повторов ровно три (суммарно ~7 с) — дальше показываем страницу
+ * входа, потому что бесконечный спиннер хуже честного «войдите заново»:
+ * cookie при этом не стирается, и повторная попытка входа сработает, как
+ * только backend оживёт.
+ */
+const BOOTSTRAP_RETRY_DELAYS_MS = [1000, 2000, 4000]
+
+const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms))
+
 /**
  * Провайдер сессии пользователя.
  * При монтировании приложения пытается восстановить сессию через
@@ -18,9 +32,15 @@ export function AuthProvider({ children }: { children: ReactNode }) {
     let cancelled = false
 
     async function bootstrap() {
-      const restored = await refreshAccessToken()
+      let outcome = await refreshAccessToken()
+      for (const delay of BOOTSTRAP_RETRY_DELAYS_MS) {
+        if (cancelled || outcome.result !== 'unavailable') break
+        await sleep(delay)
         if (cancelled) return
-      if (!restored) {
+        outcome = await refreshAccessToken()
+      }
+      if (cancelled) return
+      if (outcome.result !== 'ok') {
         setStatus('unauthenticated')
         return
       }