docs(ptica): комментарии beat-расписания считали сдвиг МСК дважды (#2464-H) #2866

Merged

bot-backend merged 1 commit from docs/2464-beat-cron-timezone into main

2026-08-13 12:26:45 +00:00

bot-backend commented

2026-08-13 11:48:49 +00:00

Collaborator

Что

celery_app.conf.timezone = "Europe/Moscow" (#1233) — crontab трактуется в МСК.
Все записи расписания так и подписаны… кроме шести подписей, оставшихся с эпохи
UTC-расписания. Они прибавляют +3 ещё раз и обещают время на три часа позже
реального:

# было
# Ночной запуск: 00:30 UTC = 03:30 МСК (Celery conf.timezone=Europe/Moscow → crontab в МСК)
"schedule": _parse_cron("30 0 * * *"),  # 00:30 UTC = 03:30 МСК

Одна строка утверждает две несовместимые вещи: «crontab в МСК» и «00:30 UTC».

Замер, а не вычитка

Логи beat-контейнера (контейнер пишет в UTC):

2026-08-10 21:30:00  Scheduler: Sending due task newbuilding-crossload-nightly
2026-08-11 21:30:00  Scheduler: Sending due task newbuilding-crossload-nightly
2026-08-12 21:30:00  Scheduler: Sending due task newbuilding-crossload-nightly

21:30 UTC = 00:30 МСК. Комментарий обещал 03:30 МСК.

Почему меняю подпись, а не расписание

Соблазн «починить» cron на 30 3 * * * — догадка о намерении, и вредная:

на 00:30 МСК ничего не наложено (ближайшие задачи — 03:00+ по будним дням);
03:30 МСК = 00:30 UTC попадает внутрь окна tradein-задания
newbuilding_enrich (window_start_hour=0, window_end_hour=1, последний прогон
13.08 00:44 UTC), а это тот же источник — tradein.houses. То есть «исправление»
завело бы ETL в гонку с продюсером.

Сегодня порядок безопасный: enrich в 00:44 UTC, crossload следующей ночью в 21:30 UTC.
Так что верное действие — привести подпись к факту и записать, почему время такое.

Ещё пять подписей

Те же UTC-ярлыки у двух отключённых записей (scrape-kn-catalog-objects-weekly,
scrape-kn-catalog-flats-weekly, закомментированы из-за WAF-бана ДОМ.РФ). Код мёртвый,
но тот, кто будет их включать, прочитает «Tuesday 04:00 UTC» и разложит соседние
задачи по несуществующей сетке. Поправил и их.

Проверка

Правка только в комментариях — объект расписания не изменился:

_parse_cron('30 0 * * *') → <crontab: 30 0 * * * (m/h/dM/MY/d)>

ruff check — clean
diff: 15 insertions / 7 deletions, все в комментариях

Refs #2464

## Что `celery_app.conf.timezone = "Europe/Moscow"` (#1233) — crontab трактуется в МСК. Все записи расписания так и подписаны… кроме шести подписей, оставшихся с эпохи UTC-расписания. Они прибавляют +3 ещё раз и обещают время на три часа позже реального: ```python # было # Ночной запуск: 00:30 UTC = 03:30 МСК (Celery conf.timezone=Europe/Moscow → crontab в МСК) "schedule": _parse_cron("30 0 * * *"), # 00:30 UTC = 03:30 МСК ``` Одна строка утверждает две несовместимые вещи: «crontab в МСК» и «00:30 UTC». ## Замер, а не вычитка Логи beat-контейнера (контейнер пишет в UTC): ``` 2026-08-10 21:30:00 Scheduler: Sending due task newbuilding-crossload-nightly 2026-08-11 21:30:00 Scheduler: Sending due task newbuilding-crossload-nightly 2026-08-12 21:30:00 Scheduler: Sending due task newbuilding-crossload-nightly ``` 21:30 UTC = **00:30 МСК**. Комментарий обещал 03:30 МСК. ## Почему меняю подпись, а не расписание Соблазн «починить» cron на `30 3 * * *` — догадка о намерении, и вредная: - на 00:30 МСК ничего не наложено (ближайшие задачи — 03:00+ по будним дням); - 03:30 МСК = 00:30 UTC попадает **внутрь окна** tradein-задания `newbuilding_enrich` (`window_start_hour=0`, `window_end_hour=1`, последний прогон 13.08 00:44 UTC), а это тот же источник — `tradein.houses`. То есть «исправление» завело бы ETL в гонку с продюсером. Сегодня порядок безопасный: enrich в 00:44 UTC, crossload следующей ночью в 21:30 UTC. Так что верное действие — привести подпись к факту и записать, почему время такое. ## Ещё пять подписей Те же UTC-ярлыки у двух **отключённых** записей (`scrape-kn-catalog-objects-weekly`, `scrape-kn-catalog-flats-weekly`, закомментированы из-за WAF-бана ДОМ.РФ). Код мёртвый, но тот, кто будет их включать, прочитает «Tuesday 04:00 UTC» и разложит соседние задачи по несуществующей сетке. Поправил и их. ## Проверка Правка только в комментариях — объект расписания не изменился: ``` _parse_cron('30 0 * * *') → <crontab: 30 0 * * * (m/h/dM/MY/d)> ``` - [x] `ruff check` — clean - [x] diff: 15 insertions / 7 deletions, все в комментариях Refs #2464

bot-backend added 1 commit 2026-08-13 11:48:50 +00:00

docs(ptica): комментарии beat-расписания считали сдвиг МСК дважды

CI Trade-In / changes (pull_request) Successful in 9s

Details

CI / changes (pull_request) Successful in 8s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Successful in 2m2s

Details

CI / backend-tests (pull_request) Successful in 16m29s

Details

dffedbd864

Celery conf.timezone=Europe/Moscow → crontab трактуется в МСК (#1233), но
шесть подписей остались с эпохи UTC-расписания и обещают на три часа
позже, чем задача реально бежит.

Замер по логам beat 10-12.08: newbuilding-crossload-nightly уходит в
21:30 UTC = 00:30 МСК, а комментарий обещал 03:30 МСК.

Расписание НЕ трогаю: на 00:30 МСК ничего не наложено, а сдвиг на 03:30
завёл бы задачу в окно tradein-задания newbuilding_enrich (00:00-01:00 UTC),
с которым она делит источник tradein.houses. Правлю подпись под факт.

Заодно те же UTC-подписи у двух отключённых записей (scrape-kn-catalog-*):
код закомментирован, но при включении вводил бы в то же заблуждение.

Проверено: _parse_cron('30 0 * * *') даёт тот же crontab — правка только
в комментариях.

Refs #2464