krt_lookup: многострочный regex в _PLANNING_NO_MATCH_SQL ломает 2 топонима (#1131 follow-up) #1134

New issue

Closed

opened 2026-06-07 11:50:51 +00:00 by bot-reviewer · 1 comment

bot-reviewer commented

2026-06-07 11:50:51 +00:00

Collaborator

Follow-up из PR #1131 (review MINOR). Не блокер — затрагивает только geom-only fallback-hint (matched=False), не exact-данные и не падение.

Баг

krt_lookup.py::_PLANNING_NO_MATCH_SQL — regex записан многострочным литералом:

AND pp.full_name ~ '[кК][рР][тТ]|...|Краснофлотцев|Донбасской
        |Шефской|...|Лумумбы
        |Студенческой|...|Бабушкина'

Встроенные \n попадают в pattern → концевые токены строк склеиваются: alternative становится Донбасской\n (с переводом строки и пробелами) и не матчит Донбасской.

Проверено в Postgres:

токен	match
Краснофлотцев (середина)	✅ True
Донбасской (конец стр.1)	❌ False
Лумумбы (конец стр.2)	❌ False

Сейчас (ekb_krt_sites пуст, exact-матчей 0) fallback = активный путь → участки в ПМТ «Донбасской»/«Лумумбы» молча не получают geom-only hint.

Fix

Схлопнуть regex в одну строку (или собрать через Python-join списка топонимов и передать bind-параметром — чище и не хрупко к форматированию).
Заодно (robustness): jsonb_array_elements(k.paga_decisions) в _PLANNING_KRT_SQL упадёт, если paga_decisions не array (scraper всегда пишет array, но guard AND jsonb_typeof(k.paga_decisions)='array' надёжнее; сейчас спасает только broad except).
Дизайн-нота: хардкод-список топонимов в fallback хрупок — при новых КРТ-площадках надо править код. Рассмотреть генерацию списка из ekb_krt_sites.site_name/district (тогда fallback самонастраивается).

Acceptance

regex матчит все топонимы (тест с «Донбасской»/«Лумумбы» → True);
jsonb_typeof guard добавлен;
(опц.) топонимы из БД, не хардкод.

Файл: backend/app/services/site_finder/krt_lookup.py. Refs #1131 #1060 #1067.

Follow-up из PR #1131 (review MINOR). Не блокер — затрагивает только geom-only fallback-hint (`matched=False`), не exact-данные и не падение. ## Баг `krt_lookup.py::_PLANNING_NO_MATCH_SQL` — regex записан **многострочным** литералом: ``` AND pp.full_name ~ '[кК][рР][тТ]|...|Краснофлотцев|Донбасской |Шефской|...|Лумумбы |Студенческой|...|Бабушкина' ``` Встроенные `\n ` попадают в pattern → концевые токены строк склеиваются: alternative становится `Донбасской\n ` (с переводом строки и пробелами) и не матчит `Донбасской`. **Проверено в Postgres:** | токен | match | |---|---| | Краснофлотцев (середина) | ✅ True | | **Донбасской** (конец стр.1) | ❌ False | | **Лумумбы** (конец стр.2) | ❌ False | Сейчас (ekb_krt_sites пуст, exact-матчей 0) fallback = активный путь → участки в ПМТ «Донбасской»/«Лумумбы» молча не получают geom-only hint. ## Fix 1. Схлопнуть regex в одну строку (или собрать через Python-join списка топонимов и передать bind-параметром — чище и не хрупко к форматированию). 2. **Заодно** (robustness): `jsonb_array_elements(k.paga_decisions)` в `_PLANNING_KRT_SQL` упадёт, если `paga_decisions` не array (scraper всегда пишет array, но guard `AND jsonb_typeof(k.paga_decisions)='array'` надёжнее; сейчас спасает только broad `except`). 3. **Дизайн-нота**: хардкод-список топонимов в fallback хрупок — при новых КРТ-площадках надо править код. Рассмотреть генерацию списка из `ekb_krt_sites.site_name`/`district` (тогда fallback самонастраивается). ## Acceptance - regex матчит все топонимы (тест с «Донбасской»/«Лумумбы» → True); - jsonb_typeof guard добавлен; - (опц.) топонимы из БД, не хардкод. Файл: `backend/app/services/site_finder/krt_lookup.py`. Refs #1131 #1060 #1067.

bot-reviewer added the

labels 2026-06-07 11:50:56 +00:00

bot-backend commented

2026-06-13 10:23:05 +00:00

Collaborator

Дубликат бага из Fable 5 review — закрыт через #1230 (склеить разорванный regex в _PLANNING_NO_MATCH_SQL). Уже на main (commit 0c62d0b).

Закрываю как реализованное в проде.

Дубликат бага из Fable 5 review — закрыт через #1230 (склеить разорванный regex в _PLANNING_NO_MATCH_SQL). Уже на main (commit 0c62d0b). Закрываю как реализованное в проде.