lekss361/gendesign

Fork 0

yandex_newbuilding_sweep: восемь прогонов подряд «обработано 5, успешно 0» со статусом done, очередь растёт 351 → 389 #2860

New issue

Closed

opened 2026-08-13 08:33:16 +00:00 by bot-backend · 4 comments

bot-backend commented

2026-08-13 08:33:16 +00:00

Collaborator

Восемь прогонов подряд: обработано 5, успешно 0, статус «успех»

Найдено побочно при разборе пустых колонок (#2674). К ним отношения не имеет — это отдельная живая поломка.

 id   старт                status  счётчики
3591  2026-08-10 04:03:25  done    total 417  pending 389  processed 5  succeeded 0
3025  2026-08-03 03:09:41  done    total 402  pending 374  processed 5  succeeded 0
2933  2026-08-02 02:28:19  done    total 395  pending 367  processed 5  succeeded 0
2843  2026-08-01 02:44:05  done    total 391  pending 363  processed 5  succeeded 0
2760  2026-07-31 03:03:38  done    total 379  pending 351  processed 5  succeeded 0
2686  2026-07-30 03:39:21  done    total 379  pending 351  processed 5  succeeded 0
2608  2026-07-29 04:28:58  done    total 379  pending 351  processed 5  succeeded 0
2531  2026-07-28 04:54:29  done    total 379  pending 351  processed 5  succeeded 0

error_text пуст у всех восьми. Прогон длится 50-77 секунд, то есть работа идёт — и заканчивается нулём.

Очередь растёт: ожидающих 351 → 389 за две недели. Витрина market.yandex_jk_enrichment стоит на 34 строках с 15.07 при 417 доступных домах.

И последний прогон — 10.08, то есть трое суток назад. Ежедневным он быть перестал: между 03.08 и 10.08 разрыв в неделю. Это отдельный вопрос к расписанию, и его надо задать до того, как чинить сам обход: если он не запускается, чинить разрешение адресов бессмысленно.

Почему сторож молчит

succeeded: 0 при processed: 5 — это полный отказ фазы разрешения адресов, но прогон помечается done, потому что исключения не было. Тот же вид, что чинили в #2674 для домкликового свипа: «блок это не наш баг, но и НЕ успех» — там mark_done заменили на banned. Здесь замена не подходит (площадка не банила), но и done неверен: прогон, не сделавший ничего из заявленного, успешным называть нельзя.

Это ровно та поломка, которую эпик #2674 описывал как самую частую: механизм исполняется, счётчик честный, вывод из него никто не делает.

Что проверить прежде, чем чинить

Почему прогон стал недельным вместо суточного — расписание, next_run_at, не выключен ли.
На чём именно спотыкается разрешение адресов — 5 обработанных, 5 неразрешённых, стабильно, без единого успеха с 26.07. Постоянство подозрительно: похоже не на «площадка иногда не отвечает», а на сломанный ключ сопоставления.
Было ли когда-нибудь иначе — найти последний прогон с succeeded > 0 и посмотреть, что менялось между ним и 26.07. Границу окна брать по этой дате, а не круглым числом.

Чего НЕ делать

Не «чинить» доведением succeeded до ненуля любой ценой. Если дома действительно не разрешаются, честный исход — назвать это и пометить прогон неуспешным, а не подогнать счётчик.

Связано: #2674 (эпик «код есть, срабатываний нет»).

## Восемь прогонов подряд: обработано 5, успешно 0, статус «успех» Найдено побочно при разборе пустых колонок (#2674). К ним отношения не имеет — это отдельная живая поломка. ``` id старт status счётчики 3591 2026-08-10 04:03:25 done total 417 pending 389 processed 5 succeeded 0 3025 2026-08-03 03:09:41 done total 402 pending 374 processed 5 succeeded 0 2933 2026-08-02 02:28:19 done total 395 pending 367 processed 5 succeeded 0 2843 2026-08-01 02:44:05 done total 391 pending 363 processed 5 succeeded 0 2760 2026-07-31 03:03:38 done total 379 pending 351 processed 5 succeeded 0 2686 2026-07-30 03:39:21 done total 379 pending 351 processed 5 succeeded 0 2608 2026-07-29 04:28:58 done total 379 pending 351 processed 5 succeeded 0 2531 2026-07-28 04:54:29 done total 379 pending 351 processed 5 succeeded 0 ``` `error_text` пуст у всех восьми. Прогон длится 50-77 секунд, то есть работа идёт — и заканчивается нулём. **Очередь растёт:** ожидающих 351 → 389 за две недели. Витрина `market.yandex_jk_enrichment` стоит на **34 строках с 15.07** при 417 доступных домах. **И последний прогон — 10.08**, то есть трое суток назад. Ежедневным он быть перестал: между 03.08 и 10.08 разрыв в неделю. Это отдельный вопрос к расписанию, и его надо задать до того, как чинить сам обход: если он не запускается, чинить разрешение адресов бессмысленно. ## Почему сторож молчит `succeeded: 0` при `processed: 5` — это полный отказ фазы разрешения адресов, но прогон помечается `done`, потому что исключения не было. Тот же вид, что чинили в #2674 для домкликового свипа: «блок это не наш баг, но и НЕ успех» — там `mark_done` заменили на `banned`. Здесь замена не подходит (площадка не банила), но и `done` неверен: **прогон, не сделавший ничего из заявленного, успешным называть нельзя**. Это ровно та поломка, которую эпик #2674 описывал как самую частую: механизм исполняется, счётчик честный, вывод из него никто не делает. ## Что проверить прежде, чем чинить 1. **Почему прогон стал недельным вместо суточного** — расписание, `next_run_at`, не выключен ли. 2. **На чём именно спотыкается разрешение адресов** — 5 обработанных, 5 неразрешённых, стабильно, без единого успеха с 26.07. Постоянство подозрительно: похоже не на «площадка иногда не отвечает», а на сломанный ключ сопоставления. 3. **Было ли когда-нибудь иначе** — найти последний прогон с `succeeded > 0` и посмотреть, что менялось между ним и 26.07. Границу окна брать по этой дате, а не круглым числом. ## Чего НЕ делать Не «чинить» доведением `succeeded` до ненуля любой ценой. Если дома действительно не разрешаются, честный исход — назвать это и пометить прогон неуспешным, а не подогнать счётчик. Связано: #2674 (эпик «код есть, срабатываний нет»).

bot-backend referenced this issue

2026-08-13 08:48:36 +00:00

[ВЛАДЕЛЬЦУ] Сводка: 8 пунктов, которые не чинятся кодом — учётки, ключи, получатель уведомлений, два решения #2704

lekss361 added the

labels 2026-08-16 10:25:26 +00:00

Light1YT referenced this issue from a commit

2026-08-19 08:12:01 +00:00

fix(tradein): фильтр выдачи Яндекса мёртв — slug ЖК ищем по странице объекта

bot-backend referenced this issue

2026-08-19 08:12:40 +00:00

fix(tradein): фильтр выдачи Яндекса мёртв — slug ЖК ищем по странице объекта (#2860) #2923

bot-backend referenced this issue

2026-08-19 08:13:06 +00:00

tradein: очередь yandex_newbuilding упирается в одни и те же пять домов — неудача ничего не помечает #2924

bot-backend referenced this issue from a commit

2026-08-19 08:37:43 +00:00

fix(tradein): фильтр выдачи Яндекса мёртв — slug ЖК ищем по странице объекта (#2860) (#2923)

bot-backend commented

2026-08-19 08:41:27 +00:00

Author

Collaborator

PR #2923 смержен, выкатка идёт. Оставляю задачу открытой до проверки на проде и фиксирую
критерий приёмки заранее, чтобы его нельзя было подогнать под результат.

Что считаю доказательством починки

Резолвер на выкаченном коде. В контейнере tradein-scraper (то есть на том коде,
что реально поехал, а не на main) прогнать резолв для дома из очереди и получить
непустой slug. Ожидаю 286394 → uspenskij.
Первый штатный прогон. Ближайший по расписанию — 24.08 около 02:00 UTC
(interval_days: 7, next_run_at 2026-08-24 02:03). Смотреть scrape_runs:
counters->>'succeeded' должен стать > 0, resolved_slug > 0.
Витрина сдвинулась. market.yandex_jk_enrichment — строк станет больше 34,
max(updated_at) уедет с 15.07.

Если 24.08 succeeded снова 0 — прогон теперь пометится failed, а не done
(это часть той же правки), то есть тишины больше не будет в любом случае.

Чего эта правка НЕ доказывает

Даже полностью рабочий резолвер разберёт очередь из 397 домов за полтора года при
limit: 5 раз в неделю, и первый же неразрешимый дом снова заблокирует голову очереди —
выборка идёт ORDER BY h.id, неудача ничего не помечает. Это отдельная задача #2924,
и без неё «починено» будет верно только про механизм, не про наполнение витрины.

Замер, на котором стоит диагноз (19.08, через сайдкар прода)

?siteId=286394  → общий список новостроек, 1 726 390 байт
                  35 уникальных ЖК, запрошенного среди них НЕТ
                  старый regex находит 128 ссылок → разметка ЦЕЛА
zhk-286394/     → ЖК «Успенский»,  slug uspenskij
zhk-2671892/    → «ШишкINN»,       slug shishkinn
zhk-999999999/  → общий список, ссылок с этим id нет → None   ← отрицательный контроль

Отпишусь сюда после пункта 1 (сегодня) и после 24.08 по пунктам 2-3.

PR #2923 смержен, выкатка идёт. Оставляю задачу открытой до проверки на проде и фиксирую критерий приёмки **заранее**, чтобы его нельзя было подогнать под результат. ## Что считаю доказательством починки 1. **Резолвер на выкаченном коде.** В контейнере `tradein-scraper` (то есть на том коде, что реально поехал, а не на main) прогнать резолв для дома из очереди и получить непустой slug. Ожидаю `286394 → uspenskij`. 2. **Первый штатный прогон.** Ближайший по расписанию — **24.08 около 02:00 UTC** (`interval_days: 7`, `next_run_at 2026-08-24 02:03`). Смотреть `scrape_runs`: `counters->>'succeeded'` должен стать **> 0**, `resolved_slug > 0`. 3. **Витрина сдвинулась.** `market.yandex_jk_enrichment` — строк станет больше 34, `max(updated_at)` уедет с 15.07. Если 24.08 `succeeded` снова 0 — прогон теперь пометится **`failed`**, а не `done` (это часть той же правки), то есть тишины больше не будет в любом случае. ## Чего эта правка НЕ доказывает Даже полностью рабочий резолвер разберёт очередь из 397 домов за полтора года при `limit: 5` раз в неделю, и первый же неразрешимый дом снова заблокирует голову очереди — выборка идёт `ORDER BY h.id`, неудача ничего не помечает. Это отдельная задача **#2924**, и без неё «починено» будет верно только про механизм, не про наполнение витрины. ## Замер, на котором стоит диагноз (19.08, через сайдкар прода) ``` ?siteId=286394 → общий список новостроек, 1 726 390 байт 35 уникальных ЖК, запрошенного среди них НЕТ старый regex находит 128 ссылок → разметка ЦЕЛА zhk-286394/ → ЖК «Успенский», slug uspenskij zhk-2671892/ → «ШишкINN», slug shishkinn zhk-999999999/ → общий список, ссылок с этим id нет → None ← отрицательный контроль ``` Отпишусь сюда после пункта 1 (сегодня) и после 24.08 по пунктам 2-3.

bot-backend commented

2026-08-19 08:46:52 +00:00

Author

Collaborator

Пункт 1 критерия выполнен — резолвер работает на выкаченном коде

Правка доехала (контейнер tradein-scraper пересоздан, маркер _JK_SLUG_PLACEHOLDER в
образе есть). Прогнал резолв в контейнере, тем же трактом, что и обход:

INFO httpx: POST http://tradein-browser:3000/fetch "200 OK"
INFO resolve_yandex_jk_slug jk_id=286394 → slug=uspenskij
RESULT jk_id=286394 slug='uspenskij'

Тот же вызов на том же контейнере до выкатки давал:

WARN resolve_yandex_jk_slug jk_id=286394: no matching slug in SERP HTML (markup drift?)
RESULT jk_id=286394 slug=None

То есть проверено не «код смержен», а что механизм отвечает по-другому на проде.

Что остаётся до закрытия

24.08 ~02:00 UTC — первый штатный прогон: жду succeeded > 0 и resolved_slug > 0
в scrape_runs. Если снова 0, прогон теперь пометится failed, а не done.
Витрина market.yandex_jk_enrichment — сейчас 34 строки, max(updated_at) 15.07.
После прогона должна сдвинуться.

Задачу держу открытой до этих двух чисел: разрешение одного дома вручную доказывает
механизм, но не наполнение витрины.

Временные probe-скрипты из контейнера удалил.

## Пункт 1 критерия выполнен — резолвер работает на выкаченном коде Правка доехала (контейнер `tradein-scraper` пересоздан, маркер `_JK_SLUG_PLACEHOLDER` в образе есть). Прогнал резолв **в контейнере**, тем же трактом, что и обход: ``` INFO httpx: POST http://tradein-browser:3000/fetch "200 OK" INFO resolve_yandex_jk_slug jk_id=286394 → slug=uspenskij RESULT jk_id=286394 slug='uspenskij' ``` Тот же вызов на том же контейнере **до** выкатки давал: ``` WARN resolve_yandex_jk_slug jk_id=286394: no matching slug in SERP HTML (markup drift?) RESULT jk_id=286394 slug=None ``` То есть проверено не «код смержен», а что механизм отвечает по-другому на проде. ## Что остаётся до закрытия - **24.08 ~02:00 UTC** — первый штатный прогон: жду `succeeded > 0` и `resolved_slug > 0` в `scrape_runs`. Если снова 0, прогон теперь пометится `failed`, а не `done`. - **Витрина** `market.yandex_jk_enrichment` — сейчас 34 строки, `max(updated_at) 15.07`. После прогона должна сдвинуться. Задачу держу открытой до этих двух чисел: разрешение одного дома вручную доказывает механизм, но не наполнение витрины. Временные probe-скрипты из контейнера удалил.

bot-backend commented

2026-08-21 09:30:28 +00:00

Author

Collaborator

Проверил, почему прогона «после фикса» нет, и разрешимы ли первые пять домов очереди

Прогона после 19.08 не было — и не должно было быть. scrape_schedules.yandex_newbuilding_sweep: interval_days: 7, последний прогон 17.08 03:38 (до выкатки фикса), next_run_at = 24.08 02:03 UTC, окно 02–05 UTC. Ожидание «20.08 ~02:00» не совпадало с расписанием — штатный прогон придёт 24.08.

Первые пять домов очереди резолвятся все — прогнал в контейнере tradein-scraper тем же трактом, что обход (через tradein-browser, задержка 8 с):

286394  → uspenskij     (ваш замер 19.08)
2671892 → shishkinn
2367237 → sadovyj-2
3003941 → dueht
609312  → petrovskij

То есть 24.08 прогон обязан дать resolved_slug = 5, succeeded > 0 и сдвинуть витрину (сейчас 34 строки, max(updated_at) 15.07). Если нет — это уже другой дефект, и прогон пометится failed по вашей правке.

Два факта к решению, не к коду:

limit: 5 при interval_days: 7 — это 5 домов в неделю на очередь 397 → ~80 недель. Параметр расписания, бюджет запросов к Яндексу; повышать ли — решение владельца.
#2924 (неудача ничего не помечает) станет видимым ровно на первом неразрешимом доме после 24.08: он встанет первым по h.id и будет занимать слот из пяти каждую неделю. Готовлю правку заранее: houses.yandex_jk_resolve_tried_at по образцу geocode_tried_at (миграция 005) — повтор не раньше чем через N дней, неудачные в конец очереди.

## Проверил, почему прогона «после фикса» нет, и разрешимы ли первые пять домов очереди **Прогона после 19.08 не было — и не должно было быть.** `scrape_schedules.yandex_newbuilding_sweep`: `interval_days: 7`, последний прогон 17.08 03:38 (до выкатки фикса), `next_run_at = 24.08 02:03 UTC`, окно 02–05 UTC. Ожидание «20.08 ~02:00» не совпадало с расписанием — штатный прогон придёт 24.08. **Первые пять домов очереди резолвятся все** — прогнал в контейнере `tradein-scraper` тем же трактом, что обход (через `tradein-browser`, задержка 8 с): ``` 286394 → uspenskij (ваш замер 19.08) 2671892 → shishkinn 2367237 → sadovyj-2 3003941 → dueht 609312 → petrovskij ``` То есть 24.08 прогон обязан дать `resolved_slug = 5, succeeded > 0` и сдвинуть витрину (сейчас 34 строки, `max(updated_at)` 15.07). Если нет — это уже другой дефект, и прогон пометится `failed` по вашей правке. **Два факта к решению, не к коду:** - `limit: 5` при `interval_days: 7` — это 5 домов в неделю на очередь 397 → ~80 недель. Параметр расписания, бюджет запросов к Яндексу; повышать ли — решение владельца. - #2924 (неудача ничего не помечает) станет видимым ровно на первом неразрешимом доме после 24.08: он встанет первым по `h.id` и будет занимать слот из пяти каждую неделю. Готовлю правку заранее: `houses.yandex_jk_resolve_tried_at` по образцу `geocode_tried_at` (миграция 005) — повтор не раньше чем через N дней, неудачные в конец очереди.

bot-backend referenced this issue

2026-08-21 09:38:30 +00:00

fix(tradein): неудача резолва yandex_jk_slug помечает дом — очередь не упирается в одни и те же пять (#2924) #3017

bot-backend referenced this issue

2026-08-21 10:00:36 +00:00

tradein: очередь yandex_newbuilding упирается в одни и те же пять домов — неудача ничего не помечает #2924

bot-backend commented

2026-08-27 16:03:14 +00:00

Author

Collaborator

Оба числа из критерия пришли — закрываю

Критерий был записан 19.08 до факта: штатный прогон 24.08 должен дать succeeded > 0 и resolved_slug > 0, витрина — сдвинуться с 34 строк и 15.07.

Прогон 4744 (24.08 02:03 UTC)

processed 5   succeeded 5   resolved_slug 5   rows_inserted 5
failed_resolve 0   failed_fetch 0   status done   195 c

Против последнего прогона до фикса (4156, 17.08): succeeded 0, resolved_slug 0, failed_resolve 5. Изменился ровно тот счётчик, ради которого правка делалась, и остальные с ним согласованы — это не «5 обработано и как-то помечено успехом», а пять разрешённых слагов и пять вставленных строк.

Витрина

market.yandex_jk_enrichment: 39 строк, max(updated_at) 2026-08-24 02:07 UTC

Было 34 строки и 15.07. Приросло ровно на 5 — сходится с rows_inserted.

Состояние расписания

enabled t · окно 02–05 UTC · interval_days 7 · limit 5
last_run 24.08 02:03 (run 4744) · next_run_at 31.08 02:38

Прогон снова еженедельный, разрыв 03.08→10.08 больше не повторяется.

Что было побочным вопросом и уже решено отдельно

Опасение «первый неразрешимый дом заблокирует голову очереди на неделю» — это #2924, закрыт. Здесь ничего не остаётся.

Оговорка из того же комментария про темп разбора очереди (5 домов в неделю на очередь 398 ≈ 80 недель) — это параметр расписания limit, решение владельца о бюджете запросов к Яндексу, а не дефект. Механизм чинили, и он починен.

## Оба числа из критерия пришли — закрываю Критерий был записан 19.08 до факта: штатный прогон 24.08 должен дать `succeeded > 0` и `resolved_slug > 0`, витрина — сдвинуться с 34 строк и 15.07. ### Прогон 4744 (24.08 02:03 UTC) ``` processed 5 succeeded 5 resolved_slug 5 rows_inserted 5 failed_resolve 0 failed_fetch 0 status done 195 c ``` Против последнего прогона до фикса (4156, 17.08): `succeeded 0, resolved_slug 0, failed_resolve 5`. Изменился ровно тот счётчик, ради которого правка делалась, и остальные с ним согласованы — это не «5 обработано и как-то помечено успехом», а пять разрешённых слагов и пять вставленных строк. ### Витрина ``` market.yandex_jk_enrichment: 39 строк, max(updated_at) 2026-08-24 02:07 UTC ``` Было 34 строки и 15.07. Приросло ровно на 5 — сходится с `rows_inserted`. ### Состояние расписания ``` enabled t · окно 02–05 UTC · interval_days 7 · limit 5 last_run 24.08 02:03 (run 4744) · next_run_at 31.08 02:38 ``` Прогон снова еженедельный, разрыв 03.08→10.08 больше не повторяется. ### Что было побочным вопросом и уже решено отдельно Опасение «первый неразрешимый дом заблокирует голову очереди на неделю» — это #2924, закрыт. Здесь ничего не остаётся. Оговорка из того же комментария про темп разбора очереди (5 домов в неделю на очередь 398 ≈ 80 недель) — это параметр расписания `limit`, решение владельца о бюджете запросов к Яндексу, а не дефект. Механизм чинили, и он починен.

bot-backend closed this issue

2026-08-27 16:03:14 +00:00