feat(tradein/domklik): пробросить isRosreestrApproved в колонку #3068
No reviewers
Labels
No labels
Fable 5 ревью
GG-форсайт
admin
analytics
auth
automation
bug
business
chore
ci
compliance
data
data-moat
docs
duplicate
dx
enhancement
feedback/max
generative
needs-discussion
needs-human
observability
pause-bots
performance
priority/p0
priority/p1
priority/p2
priority/p3
scope/backend
scope/db
scope/devops
scope/frontend
scope/qa
scrapers
security
site-finder
stage/1
stage/2
status/blocked
status/done
status/needs-analysis
status/needs-fix
status/qa
status/ready
status/review
status/wip
tech-debt
tradein
ux
week ревью 1
wontfix
ИРД
вторичка
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lekss361/gendesign#3068
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "feat/domklik-serp-field-passthrough"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Пункт 1 из #3064. Пункт 2 разобран и сознательно не сделан — см. ниже, там нашлось кое-что поинтереснее самой задачи.
Что было
BFF-ответ Домклика отдаёт
isRosreestrApproved, поле уже парсилось — и оседало только вraw_payloadjsonb. В колонкеis_rosreestr_checkedпри этом у всех 1 338 активных domklik-листингов было NULL.Соответствие однозначное и подтверждается соседним провайдером: у cian
offer["isRosreestrChecked"] → is_rosreestr_checked(cian/serp.py:1014) — прямой passthrough без трансформаций. Здесь ровно то же.registry_matchне трогается: судя по011_listings_alter.sql:54(«Совпадают площадь, адрес и этаж») и по тому, что пишет его толькоavito/detail.py, это сверка ЕГРН по трём атрибутам с детальной страницы, а не SERP-флаг «проверено». Другая величина, несмотря на похожее название.Почему пункт 2 (
is_pro_sellerизagency_name) не сделанОн был написан, а потом снят — после проверки того, что эта колонка вообще означает. Оказалось, что единого смысла у неё нет уже сейчас:
offer["isPro"]019_listings_alter_cian.sql:43: «PRO подписка у продавца»)author.category ∈ {AGENCY, AGENT}(yandex/serp.py:203-220)Это два разных признака в одной колонке. «Есть непустой
agency_name» стал бы третьим — и поехал бы в оценщик trade-in наравне с первыми двумя, причём у domklikagency_nameзаполнен у 100 % записей, то есть колонка разом получила бы 1 338 значений с новой семантикой.Правильный ход — сначала решить, что
is_pro_sellerозначает, и привести к одному смыслу всех троих. Это отдельная задача про смысл данных, а не проброс поля. Записано в #3064.Побочно это же снимает пункт 2 и из #3063 (там я предполагал, что «паттерн уже есть у cian/avito» — оказалось, что нет).
Test plan
domclick_bff_offers_sample.json— она до сих пор не была подключена ни к одному тестуassert lot.is_rosreestr_checked is True→AssertionError: assert None is True, при том чтоraw_payload["isRosreestrApproved"] == Trueуже присутствовал — то есть тест ловит именно потерю при перекладке, а не отсутствие данныхisRosreestrApprovedрезультатNone, а неFalse. Отсутствие данных не то же самое, что «проверено — не сходится»;Falseпоехал бы в оценщик как утверждение о квартире114 passed, 1 skipped(-k domclick)ruff checkс проектным конфигом — чистоОсталось в #3064
Пункт 3 —
flatComplex.id/slug→house_source/house_ext_id. Он весомее косметики: без этой привязки domklik-листинги вообще не попадают в house-matching (нет дедупа на уровне дома, нет аналитики по ЖК). Но там нужна миграция и проверка матчинга — отдельный заход.Refs #3064
BFF-ответ Домклика уже парсит isRosreestrApproved и seller.company/agent (agency_name), но клал их только в raw_payload jsonb — на проде обе колонки is_rosreestr_checked и is_pro_seller у всех 1338 активных domklik-листингов были 100% NULL, хотя данные для их заполнения были в наличии всегда. - is_rosreestr_checked: прямой passthrough isRosreestrApproved (mirror cian serp.py: offer.get("isRosreestrChecked") -> is_rosreestr_checked). НЕ то же самое, что listings.registry_match (Avito-специфичная сверка "площадь/адрес/этаж совпадают" из detail-страницы, заполняется только avito/detail.py) — поэтому registry_match не трогаем. - is_pro_seller выводится из agency_name: agency_name is None -> None (нет данных о продавце), иначе bool(agency_name). agency_name="" на практике не возникает (_extract_agency_name уже схлопывает whitespace-only в None), но проверка сделана через `is not None`, а не `!= ""`, чтобы случайно не превратить None в True. Refs #3064Проверка после написания: у is_pro_seller НЕТ единого смысла, из-за которого её можно было бы выводить из agency_name. cian — offer["isPro"], флаг ПЛАТНОЙ PRO-подписки (019_listings_alter_cian.sql:43: «PRO подписка у продавца») yandex — author.category in {AGENCY, AGENT}, категория продавца (yandex/serp.py:203-220) Это уже два разных смысла в одной колонке. «Есть непустой agency_name» стал бы третьим — и поехал бы в оценщик trade-in наравне с первыми двумя, причём у domklik agency_name заполнен у 100% записей, то есть колонка разом получила бы 1338 значений с новой семантикой. Правильный ход — сначала решить, что эта колонка вообще означает, и привести к одному смыслу всех троих. Это отдельная задача, не проброс поля. Здесь остаётся только isRosreestrApproved, у которого соответствие однозначное и подтверждается cian (offer["isRosreestrChecked"] -> is_rosreestr_checked, cian/serp.py:1014) — прямой passthrough. registry_match не трогается: судя по 011_listings_alter.sql:54 («Совпадают площадь, адрес и этаж») и по тому, что его пишет только avito/detail.py, это сверка ЕГРН по трём атрибутам с детальной страницы, а не SERP-флаг «проверено». Проверено: 114 passed, 1 skipped (-k domclick). Refs #3064