Files
docs/adr/018-minimal-runtime-coordination.md
T
ksv741 0ee54ca952 docs: record minimal runtime coordination
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
2026-10-03 21:32:35 +03:00

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.