2 commits

Author	SHA1	Message	Date
bot-backend	e9ca744e85	fix(tradein/scrapers): не путать rows_inserted/processed с честным результатным ключом ... Ревью честного run-status нашло, что _RESULT_COUNTER_KEYS ловил не только целевой yandex_newbuilding_sweep, но и rosreestr_dkp_import (rows_inserted, 66 из 67 прод- прогонов = здоровый ноль догнавшего инкрементального импорта) и newbuilding_enrich (processed — счётчик попыток, ==limit даже при частичном провале). Первое завело бы практически непрерываемый ложный zero-стрик у здорового источника, второе маскировало бы реальные отказы под measured-N. Проверено по прод-БД (2026-08-15): "succeeded" пишут ТОЛЬКО yandex_newbuilding_sweep (42 прогона/90д) и newbuilding_enrich (65/90д) — ни разу rosreestr_dkp_import; у yandex_newbuilding_sweep succeeded численно совпадает с rows_inserted на всех 42/42 прогонах. Заменил "rows_inserted"+"processed" на "succeeded" в _RESULT_COUNTER_KEYS (app-копия и byte-эквивалентная kit-копия) — цель (b) исходной правки сохранена, ложный стрик у rosreestr_dkp_import снят, попутно newbuilding_enrich получает честное измерение вместо счётчика попыток. Также поправлены докстринги test_backfill_honest_status.py — два кейса (76%/72% отказов -> 'done') проверяют только выбор финализатора mark_backfill_finished (mark_done там замокан); реальный mark_done с honest-run-status переквалифицирует их в 'failed' через _failed_ratio_too_high — это не документировалось явно.	2026-08-15 18:49:37 +03:00
bot-backend	885031420e	fix(tradein/scrapers): honest run status — стоп 'done' поверх провала и нуля ... Три прод-факта, где status='done' врал о реальном исходе прогона: - avito_detail_backfill 15.08: {"attempted":64,"failed":57,"enriched":6,"blocked":1} -> 'done'. mark_backfill_finished звал mark_done, потому что produced=6 (>0); ни _sweep_run_did_nothing (нет anchors_total/errors_count у backfill'ов), ни _phase_totally_failed (голые "attempted"/"failed" без фазового префикса) эту форму counters не ловили. Новый _failed_ratio_too_high внутри mark_done: failed/attempted >= 0.5 -> 'failed', >= 0.15 -> тоже 'failed' (другая формулировка причины в error-тексте) — 'partial' статусом не заведён: это потребовало бы DROP+ADD CHECK constraint (051_scrape_runs_extend.sql) и дообучения ещё 4 мест (Literal-фильтр admin API, статусы фронта, оба IN-списка сторожей) — тот же класс проводки, что и у ban_kind (#2686/#2764), который сознательно не стал новым статусом. - yandex_newbuilding_sweep 26.07-10.08: десять прогонов подряд 'done' при processed=5 succeeded=0 rows_inserted=0 failed_resolve=4-5 — сторож нулевого результата (_alert_if_consecutive_zero_results) не видел ни один результатный ключ этого sweep'а и молчал навсегда. _RESULT_COUNTER_KEYS дополнен rows_inserted/processed (именно в этом порядке — rows_inserted это результат, processed это попытки; иначе "5 обработано, 0 записано" замаскировалось бы под measured-5). - admin-витрина показывала new_count=0 у трёх подряд cian_full_load при реально сохранённых saved_inserted=482/214/239 — full-load'ы не пишут ни 'new_count', ни 'lots_inserted'. _column_counts дополнен saved_inserted/rows_inserted. Правки продублированы в scraper_kit/orchestration/runs.py (byte-эквивалент app.services.scrape_runs, см. докстринг модуля) для параллели: единственный текущий писатель "attempted"/"failed" (mark_backfill_finished) живёт только в app-копии, но приоритет ключей/константы держим синхронными на будущее. Не тронуто: сознательно пустые sweep'ы (errors_count=0, honest empty) и малые батчи (attempted < 3) — доля отказов на них не считается диагнозом. Tests: tests/test_honest_run_status_failed_ratio.py (41 кейс, оба модуля, включая точные прод-числа из трёх фактов выше) + regression-прогон 609 тестов по всем файлам, трогающим scrape_runs/orchestration.runs — 0 регрессий.	2026-08-15 18:06:33 +03:00