Document accepted cross-tab reauthentication, on-demand candles, native query/logging ownership and the complete deployment path. Preserve historical ADR context and link amendments through ADR 018. Related backend change: WealthLedger/backend@d698ed9
3.8 KiB
018. Минимальная runtime-координация
Status: Accepted. Уточняет cookie policy ADR 009 и prefetch policy ADR 017.
Context
Изоляция владельцев данных, атомарные финансовые изменения и локальное чтение не требуют отдельного протокола согласования каждого HTTP-ответа. Дополнительная координация оправдана только наблюдаемым поведением, которое иначе нарушается.
Decision
- Refresh сохраняет атомарную ротацию. Неуспешный refresh не меняет cookie: поздний отказ не должен удалять cookie успешного запроса. Logout очищает cookie.
- Frontend объединяет refresh и упорядочивает cookie-writing requests только внутри вкладки. Cross-tab auth synchronization не является требованием; после изменения сессии в другой вкладке допускаются reload или re-login.
- Отменой, сбросом и публикацией query results владеет TanStack Query. Смена session/connection очищает соответствующий cache; отдельные registries HTTP-запросов, access epochs и URL-wide latest-read counters не используются. Локальная auth boundary предотвращает применение старого auth result и повтор mutation под другой identity.
- Status GET читает только состояние работы. Открытый экран перечитывает
resources через
sync=observeво время работы и после завершения. Сверка hashes между status и data GET, публичные progress counters и невыдаваемые sync states не нужны. Полнота истории остаётся в resource metadata. - Свечи загружаются для запрошенного диапазона. Предзагрузки всей истории
портфеля и автоматического расширения короткого периода до
allнет. - Backend формирует согласованные entries и aggregates из одних исходных данных; frontend доверяет этому contract и не выполняет вторую сверку групп.
- Request context и HTTP completion принадлежат
nestjs-pino/pino-http. Проект сохраняет safe field filtering, redaction и route-template logging. - Deployment всегда выполняет один stop → backup → migration → readiness цикл. No-op и frontend-only оптимизации не обещаются; короткий простой принят.
Consequences
Первое открытие нового диапазона свечей может ждать загрузку. Наблюдение активной работы может перечитать неизменившиеся локальные данные, зато не требует checksum protocol. Повтор deployment создаёт новый backup и может остановить API.
DB ownership подключения, conditional publication, coverage, staging, банковские intent fingerprints и версии записей сохраняются. Отмена HTTP не считается отменой уже выполняющейся server-side transaction. Сохранённый полный forecast не заменяется candidate с изменившимися dependencies.