---

Нужно проверить серверную авторизацию при E2EE-переносе между двумя iOS-устройствами одного пользователя.

Версия клиента: iOS 1.0.45 build 146
Дата: 2026-09-03
Время клиентских логов: MSK (UTC+3)
Окно для поиска в backend-логах: примерно 10:08–10:17 UTC.

Идентификаторы:
- user_id: e3d227fc73
- доверенное/initial device: 14e42ce07a
- новое/enrolling device: fdfd820e57
- enrollment_id: 4435d42c20
- SAS flow №1: 6680091c36
- SAS flow №2: 325280a478

Симптом:
после авторизации второго iPhone первое устройство начинает массово получать 401 от E2EE API. Из-за этого оно не получает `m.key.verification.ready`, не отправляет `start`, клиент разлогинивается и SecureMessenger runtime останавливается. Перенос ключей не завершается.

Таймлайн flow 6680091c36:
- 13:08:25.537 MSK — SAS target привязан:
  14e42ce07a → fdfd820e57, enrollment=4435d42c20.
- 13:08:25.582 — `m.key.verification.request` успешно отправлен.
- 13:10:55.760 — начинается 401 на API.
- 13:10:55.833 — `secure-rooms-list` → 401.
- 13:10:55.851 — `to-device-list` → 401.
- 13:10:57.525 — второе устройство создаёт `m.key.verification.ready`.

Таким образом, 401 начинается раньше отправки `ready`.

Таймлайн flow 325280a478:
- 13:11:53.330 MSK — Matrix SAS request создан.
- 13:11:53.355 — `to-device-send` успешно отвечает 202.
- 13:14:24.578 — на устройстве 14e42ce07a начинается 401 (`to-device-list`).
- 13:14:30.632 — устройство fdfd820e57 получает verification request.
- 13:14:32.385 — пользователь подтверждает запрос, создаётся `m.key.verification.ready`.
- 13:14:32.425 — отправка `ready` успешно отвечает 202.
- 13:15:45.065 — клиент фиксирует `session_loss` и останавливает SecureMessenger.
- около 13:16:24 — после повторной авторизации устройство 14e42ce07a получает отложенный `ready`, но live SAS-flow уже отсутствует: `matrix_flow_missing`.

С 13:14:24.578 до 13:15:45.065 устройство получило 318 реальных HTTP-ответов 401:
- device-verifications — 69;
- secure-rooms-list — 65;
- to-device-list — 65;
- device-keys-fetch — 64;
- device-enrollment-requests-list — 55.

Проверьте сначала продуктовое правило:

1. Разрешены ли одному аккаунту одновременно две активные device/session?
2. Предполагает ли авторизация второго устройства отзыв access token первого?
3. Если разрешена только одна сессия, как по продуктовой логике должен работать E2EE Device Enrollment, который требует одновременно активных старого и нового устройств?

Затем проверьте реализацию backend:

- создание новой session/access token при входе второго устройства;
- отзыв или замену предыдущей сессии;
- session/token version, JTI и device binding;
- не выполняется ли revoke всех сессий пользователя вместо одной;
- одинаково ли основной API и E2EE API валидируют access token;
- нет ли рассинхронизации auth gateway/cache;
- почему токен устройства 14e42ce07a становится невалидным именно после активации fdfd820e57.

Ожидаемый результат проверки:

- Если несколько активных устройств должны поддерживаться — это баг. Найдите каноническую причину отзыва/непринятия первого токена, исправьте её и проверьте двумя параллельными device-сессиями. Оба токена должны одновременно получать 2xx на:
  - secure-rooms-list;
  - to-device-list;
  - device-keys-fetch;
  - device-enrollment-requests-list;
  - device-verifications.
  После этого проверьте полный flow:
  request → ready → start → SAS verification → key transfer → done=true.

- Если отзыв первой сессии при входе второй является осознанным продуктовым ограничением — ничего молча не меняйте. Подтвердите это со ссылкой на требование/конфигурацию и объясните, каким способом при таком ограничении должен выполняться E2EE-перенос между устройствами. Сейчас эти два требования несовместимы.

В ответе укажите:
- это баг или задуманное поведение;
- точную серверную причину;
- какие session/token были отозваны и почему;
- если это баг — что исправлено и чем проверено;
- если это продуктовая политика — где она зафиксирована и какой transfer-flow предусмотрен вместо текущего.