Тижневе оновлення даних TU
src/golden/workers/bull/queue/updateDataGoldenLadies.queue.ts
Щопонеділка о 00:10 (cron 10 0 * * 1).
Що відбувається
Дві фази, кожна — окремий процес:
Фаза 1 — Оновлення TU:
- Бере всіх незаблокованих
golden_admins - Для кожного логіниться (token) і тягне повний список своїх TU
- З відповіді витягує
name,last_name,password(на партнерському сайті),photo(URL аватара) і зберігає/оновлює уgolden_lady - Між адмінами
delay(5000)— є ліміт на апі (старе)
🪦 Legacy API. Парсинг відповіді goldenbride.net йде не як JSON, а як сирий масив рядків з магічними маркерами (
com.lady.shared.common.Satellite,com.lady.shared.common.video.VideoTypes— Java-серіалізована форма). Cookie-рядок уgetLadyFromGoldenByAdminзахардкоджений з листопада 2022. Працює тільки тому що партнерський бек не міняв формат. При першій же зміні з їхнього боку — поламається мовчки (повертатимеnullполя).TODO: коли буде час — переписати на нормальний клієнт або хоч винести cookie-стрічку у конфіг.
Фаза 2 — Конвертація mail-історії:
- Знаходить останню дату у
golden_converted_mail_history - Перебирає дати по 10 за раз, від останньої до позавчора
- Для кожного батчу конвертує
golden_history_sending_mails→golden_converted_mail_history(агрегує для подальших звітів)
Помилка фази 2 логується окремо — не впливає на статус основної фази.
Моніторинг
У production шле StackMonitoring.MonitoringWorkerLogMessage зі статусом COMPLETED / FAILED (WorkerType.UpdateProfiles).
⚠️ TODO — FAILED сюди приходить тільки якщо фаза 1 (оновлення TU) кинула throw. Конвертація mail-історії падає тихо. Треба переглянути критичність другої фази і алертити окремо якщо вона стабільно валиться.