nspd_denorm.denorm_dump: штатный пропуск feature без cad_num считается ошибкой → завышенный error-счётчик в метрике прогона #1611

New issue

Closed

opened 2026-06-16 17:19:50 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-16 17:19:50 +00:00

Collaborator

Severity: low · Категория: ложь в отчёте · Файл: backend/app/services/scrapers/nspd_denorm.py:342-355

Файл: backend/app/services/scrapers/nspd_denorm.py:342-355 (denorm_dump), источник неоднозначности — denorm_parcel_feature:193-194/223-225 и denorm_building_feature:279-280/304-306. Проблема: оба denorm_feature возвращают False как при реальном сбое UPSERT (except → logger.warning), так и при легитимном пропуске feature без cad_num (ранний return False, см. их docstring). В denorm_dump оба False попадают в else: errors_n += 1 (строки 347-348 и 354-355), поэтому возвращаемый dict {'parcels','buildings','errors'} и лог (362-368) считают каждую parcels/buildings-фичу без кад-номера ошибкой. Импакт: метрика errors используется как сигнал качества прогона — агрегируется в totals['errors'] в backfill (nspd_denorm_backfill.py:81) и логируется в harvest (nspd_sync.py:328). NSPD-дампы могут содержать parcels/buildings-фичи без cad_num (служебные/частичные WMS-ответы), которые штатно пропускаются — но они раздувают error-count, маскируя реальные сбои UPSERT и давая ложный сигнал деградации источника в мониторинге/run-статусе. Фикс: развести коды возврата — например, ввести отдельный счётчик skipped (вернуть из denorm_feature enum/None для 'нет cad_num' vs False для реального сбоя, либо возвращать tuple/Literal), и в denorm_dump инкрементировать skipped_n для пропусков, errors_n только для exception-ветки; добавить 'skipped' в возвращаемый dict и лог. Severity low: метрика/наблюдаемость, без потери данных.

Почему баг: errors в возвращаемом dict используется как метрика качества прогона. NSPD-дампы регулярно содержат фичи без cad_num (служебные/частичные ответы WMS), которые штатно пропускаются — но они раздувают error-count, маскируя реальные сбои UPSERT и давая ложный сигнал деградации источника в run-статусе/мониторинге.

Как чинить: Различать False-skip и False-error: либо вернуть из denorm_*_feature трёхзначный статус (inserted/skipped/error) или None для skip, либо завести отдельный счётчик skipped_n и не включать пропуски без cad_num в errors_n.

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

**Severity:** low · **Категория:** ложь в отчёте · **Файл:** `backend/app/services/scrapers/nspd_denorm.py:342-355` Файл: backend/app/services/scrapers/nspd_denorm.py:342-355 (denorm_dump), источник неоднозначности — denorm_parcel_feature:193-194/223-225 и denorm_building_feature:279-280/304-306. Проблема: оба denorm_*_feature возвращают False как при реальном сбое UPSERT (except → logger.warning), так и при легитимном пропуске feature без cad_num (ранний `return False`, см. их docstring). В denorm_dump оба False попадают в `else: errors_n += 1` (строки 347-348 и 354-355), поэтому возвращаемый dict {'parcels','buildings','errors'} и лог (362-368) считают каждую parcels/buildings-фичу без кад-номера ошибкой. Импакт: метрика errors используется как сигнал качества прогона — агрегируется в totals['errors'] в backfill (nspd_denorm_backfill.py:81) и логируется в harvest (nspd_sync.py:328). NSPD-дампы могут содержать parcels/buildings-фичи без cad_num (служебные/частичные WMS-ответы), которые штатно пропускаются — но они раздувают error-count, маскируя реальные сбои UPSERT и давая ложный сигнал деградации источника в мониторинге/run-статусе. Фикс: развести коды возврата — например, ввести отдельный счётчик `skipped` (вернуть из denorm_*_feature enum/None для 'нет cad_num' vs False для реального сбоя, либо возвращать tuple/Literal), и в denorm_dump инкрементировать skipped_n для пропусков, errors_n только для exception-ветки; добавить 'skipped' в возвращаемый dict и лог. Severity low: метрика/наблюдаемость, без потери данных. **Почему баг:** errors в возвращаемом dict используется как метрика качества прогона. NSPD-дампы регулярно содержат фичи без cad_num (служебные/частичные ответы WMS), которые штатно пропускаются — но они раздувают error-count, маскируя реальные сбои UPSERT и давая ложный сигнал деградации источника в run-статусе/мониторинге. **Как чинить:** Различать False-skip и False-error: либо вернуть из denorm_*_feature трёхзначный статус (inserted/skipped/error) или None для skip, либо завести отдельный счётчик skipped_n и не включать пропуски без cad_num в errors_n. --- <sub>deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.85 · unit B34</sub>