04-tu-links

Зв’язки TU в часі

src/tu-links/ — проєкція подій призначень TU і журналу топів Stack у відрізки часу: хто працював на TU і за ким вона була закріплена в будь-який момент.

Дані: project_tu_links · Swagger: лише internal-роути

Що робить модуль

  • Згортає tu_logs і журнал топів Stack (stack_log_top_managers) у відрізки [from, to) двох типів: work — хто працює на TU, assigned — за ким TU закріплена.
  • Відповідає на «TU користувача за період» і «хто був на TU в момент» запитом по індексу, без читання логів.
  • Оновлюється інкрементально після кожної зміни; повна перебудова виконується тим самим алгоритмом.

Логіка

Правила work

  • Логін оператора відкриває його відрізок.
  • Відрізок закривають лише логін іншого оператора, зняття оператора, що працює, або зняття його тімліда (TU переходить у фрі). Зняття чи заміна іншого оператора на work не впливає.
  • Активація, деактивація і видалення TU змінюють active. Створення не означає активності: стан визначається наступними подіями або поточним статусом TU.
  • Рівно один відкритий work на TU; оператор null — TU у фрі.

Правила assigned

  • Призначення відкриває відрізок, зняття тієї ж ролі й користувача закриває; повтори ігноруються.
  • До 3 відкритих операторів (з тімлідом зміни) і 3 тімлідів на TU.

Топ і client manager

Властивості моменту, а не окремі записи. Зміна топа тімліда розрізає відкриті записи з цим тімлідом; зміна client manager TU — усі відкриті записи TU. Client manager однаковий в усіх записах TU на момент часу.

Зв’язки з часу до початку логів (перша подія — зняття, або в TU призначення є, а в логах немає) відкриваються з першої події TU.

Запис

Одна згортка (tu-links.fold.ts) для наката й перебудови. Пише лише різницю з поточними записами; повторний логін того самого оператора нічого не змінює.

ХтоКолиЩо
Призначення TUпісля кожної TU у зміні призначень: frontend, detach зі Stack, refreshapply від моменту до запису
Refresh TUпісля подій життєвого циклу TUapply від часу синхронізації
Stackпісля зміни топа тімлідаapply-team-leads: TU тімліда беруться з project_tu_links
вручну, міграціїремонт, первинне заповненняrebuild для проєкту або вибраних TU, від дати

apply перечитує логи TU від ранішого з моменту події та останньої зміни запису: підхоплює подію, записану пізніше за свій час, і пропущений раніше накат. Якщо стан на цей момент неузгоджений, TU перебудовується з початку. Обробка однієї TU — під локом project:tu:links:<tuId> (60 с): подія, що надійшла під час перебудови, програється після неї. Журнал топів читається на кожен apply, без кешу на перебудову.

Читання

find-by-team-lead — команда тімліда за період одним запитом по індексу тімліда: TU, закріплені за ним, і роботу на них його операторів; оператори з їхніми TU. Відрізки обрізаються періодом, відкриті — поточним моментом. Споживачів у платформі поки немає: статистика і дашборди читають relations.

Internal API

РоутХто викликаєНавіщо
POST /v2/internal/tu-links/apply— (призначений для логінів зі stack-golden)накат для вибраних TU від моменту
POST /v2/internal/tu-links/apply-team-leadsStackнакат після зміни топа тімліда
POST /v2/internal/tu-links/rebuildвручну, вкладка міграційповна перебудова проєкту або вибраних TU
POST /v2/internal/tu-links/find-by-team-lead—команда тімліда за період

Звірка з legacy (Golden, дамп)

  • 1,37 млн подій → 473 тис. записів; повна перебудова ~40 с, накат ~7 мс на TU.
  • Оператор і тімлід work збігаються зі штампом golden_statistics у 990 849 з 996 238 рядків за 28.11.2025–21.09.2026; з січня 2026 — практично 100 %. Розбіжності — листопад–грудень 2025, перехід legacy на правило логінів.
  • Client manager на кінець доби збігається з golden_statistics_relations у 51 523 з 51 527 TU-днів за серпень 2026.

Нюанси

  • Логіни в Golden є лише з 2025-11-25: до цієї дати work — фрі. У Udate логінів немає.
  • Прогалини legacy-логів: 14 TU Golden мають відкритого оператора без зняття; 110 неактивних TU без подій активації — уся їхня історія неактивна; журнал топів — лише з 2024-07-01.

Борг

  • Логін оператора пише в tu_logs stack-golden, але apply не викликає: work оновлюється лише при наступному накаті цієї TU. Вирішиться переносом логінів на платформу.