[scrape_kn_catalog_objects] force=True «Загрузить все» молча ограничивается LIMIT 300 — каталог недогружается #1622

New issue

Closed

opened 2026-06-16 17:21:53 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-16 17:21:53 +00:00

Collaborator

Severity: medium · Категория: logic/contract-mismatch · Файл: backend/app/workers/tasks/scrape_kn_catalog_objects.py:38-56, 78-80, 98

Файл: backend/app/workers/tasks/scrape_kn_catalog_objects.py. _SELECT_TARGETS_SQL (строка 54) ВСЕГДА содержит LIMIT :max_objects. Параметр force в SQL (строки 44-47, CAST(:force AS boolean) OR ...) снимает только фильтр «уже сегодня обновлён», но НЕ снимает LIMIT. При не заданном max_objects limit = _DEFAULT_MAX_OBJECTS = 300 (строки 59, 98). Документация задачи (docstring модуля строка 10, docstring функции строки 78-80) и admin-эндпоинт (admin_scrape.py:1497-1504, описание поля force; docstring строка 1520) обещают, что force=True грузит ВСЕ объекты последнего snapshot. Подтверждено: TriggerKnCatalogObjectsRequest.max_objects ограничен le=2000 (admin_scrape.py:1496), а при вызове force=True без max_objects (естественный путь «Загрузить все») kwargs не содержит max_objects (admin_scrape.py:1528-1529) → таск берёт 300.

Импакт: на регионе 66, где в snapshot обычно сотни-тысячи объектов, force=True грузит только первые 300 (ORDER BY catalog_scraped_at NULLS FIRST), остальные молча не скрапятся — без ошибки/предупреждения. ~25 NULL-колонок (wall_type, energy_eff, parking_*, scores) остаются пустыми у большинства объектов, хотя админ считает каталог полностью прогнанным. Тихая неполнота данных на явном админ-действии, противоречащая задокументированному и UI-обещанному поведению. Severity medium (не падение, но silent data incompleteness на явном действии).

Фикс: при force=True не применять LIMIT (например, делать LIMIT NULL / ALL когда force и max_objects не задан) или поднять/убрать потолок le=2000 для max_objects вместе с явным переопределением limit при force. Также синхронизировать docstring/описание поля с фактическим поведением.

Почему баг: Самый естественный путь UI «Загрузить все» — нажать force=True без указания max_objects (так и описано в admin: force=True само по себе значит «грузить ВСЕ»). В этом случае max_objects=None → limit=300 → SQL грузит только первые 300 объектов snapshot, упорядоченных по catalog_scraped_at NULLS FIRST. Если в последнем snapshot >300 объектов (для региона 66 их обычно сотни-тысячи), остальные молча НЕ скрапятся — никакой ошибки/предупреждения. Админ думает что прогнал весь каталог, а ~25 NULL-колонок (wall_type, energy_eff, parking_, domrf_score_) остаются пустыми у большинства объектов. Это тихая неполнота данных на явном админ-действии, противоречащая задокументированному и UI-обещанному поведению.

Как чинить: Либо при force=True снимать LIMIT (например, не подставлять LIMIT когда force, или трактовать max_objects=None+force как «без лимита»), либо привести документацию/UI к реальности: force снимает только skip-today, но всё равно режется max_objects (по умолчанию 300, max 2000). Если оставить лимит — логировать WARNING когда число кандидатов упёрлось в LIMIT, чтобы неполнота была видна.

_{deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.9 · unit B45}

**Severity:** medium · **Категория:** logic/contract-mismatch · **Файл:** `backend/app/workers/tasks/scrape_kn_catalog_objects.py:38-56, 78-80, 98` Файл: backend/app/workers/tasks/scrape_kn_catalog_objects.py. _SELECT_TARGETS_SQL (строка 54) ВСЕГДА содержит `LIMIT :max_objects`. Параметр force в SQL (строки 44-47, `CAST(:force AS boolean) OR ...`) снимает только фильтр «уже сегодня обновлён», но НЕ снимает LIMIT. При не заданном max_objects limit = _DEFAULT_MAX_OBJECTS = 300 (строки 59, 98). Документация задачи (docstring модуля строка 10, docstring функции строки 78-80) и admin-эндпоинт (admin_scrape.py:1497-1504, описание поля force; docstring строка 1520) обещают, что force=True грузит ВСЕ объекты последнего snapshot. Подтверждено: TriggerKnCatalogObjectsRequest.max_objects ограничен `le=2000` (admin_scrape.py:1496), а при вызове force=True без max_objects (естественный путь «Загрузить все») kwargs не содержит max_objects (admin_scrape.py:1528-1529) → таск берёт 300. Импакт: на регионе 66, где в snapshot обычно сотни-тысячи объектов, force=True грузит только первые 300 (ORDER BY catalog_scraped_at NULLS FIRST), остальные молча не скрапятся — без ошибки/предупреждения. ~25 NULL-колонок (wall_type, energy_eff, parking_*, scores) остаются пустыми у большинства объектов, хотя админ считает каталог полностью прогнанным. Тихая неполнота данных на явном админ-действии, противоречащая задокументированному и UI-обещанному поведению. Severity medium (не падение, но silent data incompleteness на явном действии). Фикс: при force=True не применять LIMIT (например, делать LIMIT NULL / ALL когда force и max_objects не задан) или поднять/убрать потолок le=2000 для max_objects вместе с явным переопределением limit при force. Также синхронизировать docstring/описание поля с фактическим поведением. **Почему баг:** Самый естественный путь UI «Загрузить все» — нажать force=True без указания max_objects (так и описано в admin: force=True само по себе значит «грузить ВСЕ»). В этом случае max_objects=None → limit=300 → SQL грузит только первые 300 объектов snapshot, упорядоченных по catalog_scraped_at NULLS FIRST. Если в последнем snapshot >300 объектов (для региона 66 их обычно сотни-тысячи), остальные молча НЕ скрапятся — никакой ошибки/предупреждения. Админ думает что прогнал весь каталог, а ~25 NULL-колонок (wall_type, energy_eff, parking_*, domrf_score_*) остаются пустыми у большинства объектов. Это тихая неполнота данных на явном админ-действии, противоречащая задокументированному и UI-обещанному поведению. **Как чинить:** Либо при force=True снимать LIMIT (например, не подставлять LIMIT когда force, или трактовать max_objects=None+force как «без лимита»), либо привести документацию/UI к реальности: force снимает только skip-today, но всё равно режется max_objects (по умолчанию 300, max 2000). Если оставить лимит — логировать WARNING когда число кандидатов упёрлось в LIMIT, чтобы неполнота была видна. --- <sub>deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.9 · unit B45</sub>