lekss361/gendesign

Fork 0

DomClick Layer B (deep detail-backfill) заблокирован QRATOR — нужен dedicated residential RU proxy #2000

New issue

Closed

opened 2026-06-27 13:39:51 +00:00 by lekss361 · 8 comments

lekss361 commented

2026-06-27 13:39:51 +00:00

Owner

Суть

Глубокий detail DomClick (renovation-enum, wallType/floorType, livingArea/kitchenArea, полная история цен, owners_count, AVM) живёт ТОЛЬКО на card-странице (ekaterinburg.domclick.ru/card/... + XHR offer-card.domclick.ru), которая за QRATOR reputation-403 на всех прод mobile-прокси. Layer A (поиск через bff-search-web) — работает (QRATOR там мягкий).

Аудит транспорта (live, 2026-06-27)

QRATOR на card/offer-card = reputation-403, не JS-challenge. Страница 403 | Домклик: «Похоже, ваш запрос выглядит необычно… отключите VPN», показывает IP. Реальный браузер её НЕ обходит (camoufox на проде 5/5, 3/3 → 403).
bff-search-web — мягкий: тот же прокси отдаёт JSON. Поэтому Layer A жив.
Прокси-пул — shared mobileproxy (auv/ha/aup.mobileproxy.space, mproxy.site). Exit-IP = настоящие MegaFon/Tele2 (mobile:true, proxy:false по ip-api) — QRATOR метит НЕ по типу IP, а по поведенческой репутации конкретного IP (общий пул сожжён множеством скрейперов). Свежеротированный IP проходит РАЗОВО (cian отдал 352 КБ один раз), затем сгорает; changeip-ротация не спасает (4/4 → 403).
Чистый residential IP (домашний) отдаёт карточку полностью (playwright 359 КБ, __SSR_STATE__ со всеми полями). Подтверждает: нужен IP с чистой репутацией.

Что уже сделано

Layer A+ (#1999, смержено): обогащение поиска — description→repair-инференс, description_minhash, agency_name, is_sber_collateral, discount, dups. Полезный срез БЕЗ QRATOR-риска.
Layer B код готов и сохранён в ветке feat/tradein-domclick-detail-backfill (commit eef23071, DORMANT): parser на реальных __SSR_STATE__ путях + AVM, orchestrator (зеркало avito_detail_backfill), schedule 139 (enabled=false). Тесты зелёные. НЕ мержить до прокси.

Что нужно для разблокировки

Dedicated/приватный residential RU proxy (не shared mobileproxy-пул) с чистой репутацией. Затем:

config.py + browser/server.py _provider_for_url: роут *.domclick.ru card/offer-card хостов → этот прокси (env-gated, напр. DOMCLICK_DETAIL_PROXY_URL).
Прод-smoke: BrowserFetcher на card → __SSR_STATE__ присутствует.
Merge ветки feat/tradein-domclick-detail-backfill → enable schedule UPDATE scrape_schedules SET enabled=true WHERE source='domclick_detail_backfill'.

Vault: research/Domclick_Bff_Api_Contract_Jun27.md (полный аудит + реальные __SSR_STATE__ пути).

## Суть Глубокий detail DomClick (renovation-enum, wallType/floorType, livingArea/kitchenArea, полная история цен, owners_count, AVM) живёт ТОЛЬКО на card-странице (`ekaterinburg.domclick.ru/card/...` + XHR `offer-card.domclick.ru`), которая **за QRATOR reputation-403 на всех прод mobile-прокси**. Layer A (поиск через `bff-search-web`) — работает (QRATOR там мягкий). ## Аудит транспорта (live, 2026-06-27) - **QRATOR на card/offer-card = reputation-403, не JS-challenge.** Страница `403 | Домклик`: «Похоже, ваш запрос выглядит необычно… отключите VPN», показывает IP. Реальный браузер её НЕ обходит (camoufox на проде 5/5, 3/3 → 403). - **bff-search-web — мягкий**: тот же прокси отдаёт JSON. Поэтому Layer A жив. - **Прокси-пул — shared mobileproxy** (`auv/ha/aup.mobileproxy.space`, `mproxy.site`). Exit-IP = настоящие MegaFon/Tele2 (`mobile:true, proxy:false` по ip-api) — QRATOR метит НЕ по типу IP, а по **поведенческой репутации конкретного IP** (общий пул сожжён множеством скрейперов). Свежеротированный IP проходит РАЗОВО (cian отдал 352 КБ один раз), затем сгорает; changeip-ротация не спасает (4/4 → 403). - **Чистый residential IP (домашний) отдаёт карточку** полностью (playwright 359 КБ, `__SSR_STATE__` со всеми полями). Подтверждает: нужен IP с чистой репутацией. ## Что уже сделано - **Layer A+ (#1999, смержено):** обогащение поиска — `description`→repair-инференс, `description_minhash`, `agency_name`, `is_sber_collateral`, discount, dups. Полезный срез БЕЗ QRATOR-риска. - **Layer B код готов и сохранён** в ветке `feat/tradein-domclick-detail-backfill` (commit `eef23071`, DORMANT): parser на реальных `__SSR_STATE__` путях + AVM, orchestrator (зеркало avito_detail_backfill), schedule `139` (enabled=false). Тесты зелёные. **НЕ мержить до прокси.** ## Что нужно для разблокировки **Dedicated/приватный residential RU proxy** (не shared mobileproxy-пул) с чистой репутацией. Затем: 1. `config.py` + `browser/server.py _provider_for_url`: роут `*.domclick.ru` card/offer-card хостов → этот прокси (env-gated, напр. `DOMCLICK_DETAIL_PROXY_URL`). 2. Прод-smoke: `BrowserFetcher` на card → `__SSR_STATE__` присутствует. 3. Merge ветки `feat/tradein-domclick-detail-backfill` → enable schedule `UPDATE scrape_schedules SET enabled=true WHERE source='domclick_detail_backfill'`. Vault: `research/Domclick_Bff_Api_Contract_Jun27.md` (полный аудит + реальные `__SSR_STATE__` пути).

lekss361 commented

2026-06-27 15:24:58 +00:00

Author

Owner

Апдейт: рабочий локальный раннер + находка про headless

Дифференциатор QRATOR — не только IP, а РЕЖИМ HEADLESS. Verified live с одного и того же домашнего IP:

chromium launch(headless=True) (старый headless) → 401 / 403 | Домклик, нет __SSR_STATE__;
chromium --headless=new (или headed) → 200 + полный __SSR_STATE__ (~330 КБ).

QRATOR фингерпринтит старый headless-shell. Т.е. на сожжённых прокси-IP блок по IP-репутации, а на чистом IP — ещё и по headless-фингерпринту. (Для прод-пула camoufox это, вероятно, не проблема — он anti-detect; прод-блокер остаётся IP.)

Рабочий обход (без прокси): tradein-mvp/backend/scripts/domclick_local_runner.py (ветка feat/tradein-domclick-detail-backfill, commit 480ecc90) — self-contained раннер на домашнем residential IP + new-headless chromium. Enumerate via bff (Layer A) + card __SSR_STATE__ (Layer B) → JSONL. Verified live: карточки отдаются с полным detail (repair/areas/priceHistory/egrn/owners/wall/floor). Пейсинг: 12-30с между карточками, human-break, retry-on-403, resume. ~100-150 карточек/час → full ~6400 ≈ 45-65ч (запускать инкрементально/ночами). JSONL ингестится в tradein DB отдельным шагом.

Это разблокирует Layer B без dedicated residential proxy (для одноразового/инкрементального бэкфилла с машины оператора). Прод-автоматизация (через пул) по-прежнему требует чистый IP.

## Апдейт: рабочий локальный раннер + находка про headless **Дифференциатор QRATOR — не только IP, а РЕЖИМ HEADLESS.** Verified live с одного и того же домашнего IP: - chromium `launch(headless=True)` (старый headless) → `401 / 403 | Домклик`, нет `__SSR_STATE__`; - chromium **`--headless=new`** (или headed) → `200` + полный `__SSR_STATE__` (~330 КБ). QRATOR фингерпринтит старый headless-shell. Т.е. на сожжённых прокси-IP блок по IP-репутации, а на чистом IP — ещё и по headless-фингерпринту. (Для прод-пула camoufox это, вероятно, не проблема — он anti-detect; прод-блокер остаётся IP.) **Рабочий обход (без прокси):** `tradein-mvp/backend/scripts/domclick_local_runner.py` (ветка `feat/tradein-domclick-detail-backfill`, commit `480ecc90`) — self-contained раннер на **домашнем residential IP + new-headless chromium**. Enumerate via bff (Layer A) + card `__SSR_STATE__` (Layer B) → JSONL. Verified live: карточки отдаются с полным detail (repair/areas/priceHistory/egrn/owners/wall/floor). Пейсинг: 12-30с между карточками, human-break, retry-on-403, resume. ~100-150 карточек/час → full ~6400 ≈ 45-65ч (запускать инкрементально/ночами). JSONL ингестится в tradein DB отдельным шагом. Это разблокирует Layer B **без** dedicated residential proxy (для одноразового/инкрементального бэкфилла с машины оператора). Прод-автоматизация (через пул) по-прежнему требует чистый IP.

lekss361 referenced this issue

2026-06-27 16:15:01 +00:00

[BLOCKED #2000] feat(tradein/domclick): Layer B detail-backfill + local runner + JSONL ingest #2005

bot-backend referenced this issue from a commit

2026-06-28 07:28:09 +00:00

feat(tradein/domclick): local-runner + ingest tooling → main (split from parked Layer-B)

lekss361 referenced this issue

2026-06-28 07:28:32 +00:00

feat(tradein/domclick): local-runner + ingest tooling (mergeable split from #2005) #2033

lekss361 referenced this issue

2026-07-02 16:07:26 +00:00

[BLOCKED #2000] feat(tradein/domclick): Layer B detail-backfill + local runner + JSONL ingest #2005

lekss361 commented

2026-07-02 16:07:38 +00:00

Author

Owner

Апдейт 2026-07-02: PR #2005 закрыт без merge (proxy-независимая часть — runner/ingest/парсер/тесты — уже в main через 43b392b8; сверено, diff = 0). Ветка feat/tradein-domclick-detail-backfill сохранена как парковка Layer-B.

Корректировка шага 3 плана разблокировки: вместо «merge ветки» → резать свежий PR от актуального main: (а) перенумеровать миграцию (слот 139 занят 139_premium_houses.sql); (б) оркестратор (tasks/domclick_detail_backfill.py + scheduler wiring) переложить на scraper-kit core, если strangler-рефактор (#2132) к тому моменту доедет до domclick.

Апдейт 2026-07-02: PR #2005 закрыт без merge (proxy-независимая часть — runner/ingest/парсер/тесты — уже в main через 43b392b8; сверено, diff = 0). Ветка `feat/tradein-domclick-detail-backfill` сохранена как парковка Layer-B. Корректировка шага 3 плана разблокировки: вместо «merge ветки» → **резать свежий PR от актуального main**: (а) перенумеровать миграцию (слот 139 занят `139_premium_houses.sql`); (б) оркестратор (`tasks/domclick_detail_backfill.py` + scheduler wiring) переложить на scraper-kit core, если strangler-рефактор (#2132) к тому моменту доедет до domclick.

lekss361 added the

labels 2026-07-04 10:24:25 +00:00

lekss361 referenced this issue

2026-07-04 14:20:45 +00:00

DomClick scraper мёртв: VPS-IP заблокирован QRATOR + редизайн сайта (нужен прокси + rewrite на новый API) #1846

lekss361 commented

2026-07-04 14:20:58 +00:00

Author

Owner

Реконциляция (2026-07-04)

Уточнение к формулировке «Layer B код готов и dormant»: код в scraper_kit.providers.domclick.detail — НЕ неиспользуемый, он активно вызывается backend/scripts/ingest_domclick_jsonl.py. Автоматизированный прод-пайплайн (Celery task + schedule id=139 из ветки feat/tradein-domclick-detail-backfill, commit eef23071) действительно не вошёл в main (сознательно отброшен при мерже #2033) — но вместо него в main уже есть рабочая ручная альтернатива: domclick_local_runner.py (домашний IP, playwright, paced) → JSONL → ingest_domclick_jsonl.py → БД. Ветка feat/tradein-domclick-detail-backfill теперь дважды мертва: её польза уже в main (кit-импортами), а её собственный код ссылается на legacy app.services.scrapers.*, удалённый в final-E (#2397/#2419) — смерджить её сейчас невозможно без полного переписывания. Удалена (все 3 remote).

Также нашли неточность в докстринге detail.py («транспорт через cian-прокси — QRATOR-clean») — устаревшее утверждение из первого коммита, до того как local_runner.py-исследование показало реальный механизм («свежий IP в ЛЮБОМ пуле проходит разово → сгорает», не cian-специфичный обход). Мелкая правка докстринга — приложим к следующему PR по domclick.

Прокси-апдейт

В проде уже есть дедицированный residential ASocks-прокси (scrape_proxies.id=1, оплачен до 2026-07-28, автопродление ВКЛ) — ровно тот тип чистого residential IP, который по этому issue проходит QRATOR на card-странице. Мигрируем provider_affinity на 'domclick' (миграция 173_scrape_proxies_add_domclick_affinity.sql, в работе) — это потенциально даёт путь к автоматизации Layer B без 45-65ч ручного domclick_local_runner.py на каждый полный свод. Требует прод-smoke после миграции: убедиться, что residential IP реально проходит card-страницу устойчиво (не одноразово, как burn-эффект свежих IP в общем пуле).

Refs #2397 (декоммишн, объясняет разрыв импортов), #2033 (откуда пришла рабочая ручная альтернатива).

## Реконциляция (2026-07-04) Уточнение к формулировке «Layer B код готов и dormant»: код в `scraper_kit.providers.domclick.detail` — **НЕ неиспользуемый**, он активно вызывается `backend/scripts/ingest_domclick_jsonl.py`. Автоматизированный прод-пайплайн (Celery task + schedule id=139 из ветки `feat/tradein-domclick-detail-backfill`, commit `eef23071`) действительно не вошёл в main (сознательно отброшен при мерже #2033) — но вместо него в main уже есть **рабочая ручная альтернатива**: `domclick_local_runner.py` (домашний IP, playwright, paced) → JSONL → `ingest_domclick_jsonl.py` → БД. Ветка `feat/tradein-domclick-detail-backfill` теперь дважды мертва: её польза уже в main (кit-импортами), а её собственный код ссылается на legacy `app.services.scrapers.*`, удалённый в final-E (#2397/#2419) — смерджить её сейчас невозможно без полного переписывания. **Удалена** (все 3 remote). Также нашли неточность в докстринге `detail.py` («транспорт через cian-прокси — QRATOR-clean») — устаревшее утверждение из первого коммита, до того как `local_runner.py`-исследование показало реальный механизм («свежий IP в ЛЮБОМ пуле проходит разово → сгорает», не cian-специфичный обход). Мелкая правка докстринга — приложим к следующему PR по domclick. ## Прокси-апдейт В проде уже есть **дедицированный residential ASocks-прокси** (`scrape_proxies.id=1`, оплачен до 2026-07-28, автопродление ВКЛ) — ровно тот тип чистого residential IP, который по этому issue проходит QRATOR на card-странице. Мигрируем `provider_affinity` на `'domclick'` (миграция `173_scrape_proxies_add_domclick_affinity.sql`, в работе) — это потенциально даёт путь к **автоматизации** Layer B без 45-65ч ручного `domclick_local_runner.py` на каждый полный свод. Требует прод-smoke после миграции: убедиться, что residential IP реально проходит card-страницу устойчиво (не одноразово, как burn-эффект свежих IP в общем пуле). Refs #2397 (декоммишн, объясняет разрыв импортов), #2033 (откуда пришла рабочая ручная альтернатива).

lekss361 referenced this issue from a commit

2026-07-04 14:21:15 +00:00

chore(tradein/proxy-pool): добавить domclick в provider_affinity CHECK (residential ASocks для #2000)

lekss361 referenced this issue

2026-07-04 14:23:20 +00:00

chore(tradein/proxy-pool): добавить domclick в provider_affinity CHECK (residential ASocks для #2000) #2426

lekss361 referenced this issue from a commit

2026-07-04 14:25:43 +00:00

Merge pull request 'chore(tradein/proxy-pool): добавить domclick в provider_affinity CHECK (residential ASocks для #2000)' (#2426) from chore/tradein-scrape-proxies-domclick-affinity into main

lekss361 commented

2026-07-04 14:38:30 +00:00

Author

Owner

Апдейт: residential ASocks-прокси НЕ работает (2026-07-04, live-тест)

Коррекция к предыдущему комментарию — миграция применена, id=1 привязан к provider_affinity='domclick', но сам прокси недоступен:

Live-тест 3 независимыми клиентами (curl, httpx, playwright) — TCP SYN на 212.8.249.134:10423 проходит, но прокси-сервер молча рвёт соединение до любого HTTP-ответа (ни 407, ничего). Не QRATOR — до domclick.ru запрос не доходит вообще, обрыв на самом прокси-сервере.

Контрольный факт: тестовое окружение случайно оказалось на чистом Moscow MGTS residential IP (95.165.147.218, mobile:false,proxy:false,hosting:false) — card-страница прошла БЕЗ прокси с первой попытки, полный __SSR_STATE__. Ещё раз подтверждает механизм (чистый residential IP = проход), но не даёт рабочего управляемого канала.

needs-human: проверить ASocks-панель — статус порта id=1, IP-whitelist (не совпадает ли с IP ручного теста юзера), не истекла/занята ли сессия. До починки — прокси-путь к автоматизации Layer B не подтверждён, domclick_local_runner.py (ручной, домашний IP) остаётся единственным рабочим каналом.

## Апдейт: residential ASocks-прокси НЕ работает (2026-07-04, live-тест) Коррекция к предыдущему комментарию — миграция применена, `id=1` привязан к `provider_affinity='domclick'`, но **сам прокси недоступен**: Live-тест 3 независимыми клиентами (curl, httpx, playwright) — TCP SYN на `212.8.249.134:10423` проходит, но прокси-сервер молча рвёт соединение до любого HTTP-ответа (ни `407`, ничего). Не QRATOR — до domclick.ru запрос не доходит вообще, обрыв на самом прокси-сервере. Контрольный факт: тестовое окружение случайно оказалось на чистом Moscow MGTS residential IP (`95.165.147.218`, `mobile:false,proxy:false,hosting:false`) — card-страница прошла БЕЗ прокси с первой попытки, полный `__SSR_STATE__`. Ещё раз подтверждает механизм (чистый residential IP = проход), но не даёт рабочего управляемого канала. **needs-human**: проверить ASocks-панель — статус порта id=1, IP-whitelist (не совпадает ли с IP ручного теста юзера), не истекла/занята ли сессия. До починки — прокси-путь к автоматизации Layer B не подтверждён, `domclick_local_runner.py` (ручной, домашний IP) остаётся единственным рабочим каналом.

lekss361 commented

2026-07-04 14:48:04 +00:00

Author

Owner

Финальный апдейт после обновления whitelist (2026-07-04)

После того как юзер обновил IP-whitelist на ASocks-панели — базовая connectivity починилась: curl -x <proxy> https://i.pn с прод-VPS → успех, exit IP 185.181.247.139 (Moscow, AS35048 Biterika Group LLC, mobile:false,proxy:false,hosting:false — чистый residential-профиль).

НО реальный card-фетч через прод-браузер (tradein-browser camoufox, POST /fetch) — 3/3 попытки провалены: 1× TimeoutError: Page.goto Timeout 60000ms, 2× Error: Page.goto: NS_ERROR_PROXY_BAD_GATEWAY. Это ошибка прокси-туннеля при браузерной навигации, НЕ QRATOR-ответ (до domclick запрос не доходит вообще) — при этом базовый curl через тот же прокси работает нормально.

Технический контекст: DomClick намеренно falls through на generic-провайдера в tradein-browser (нет BROWSER_PROXY_DOMCLICK) → SCRAPER_PROXY_URL = именно этот ASocks-порт (browser/server.py:551-553). Т.е. serp-трафик (Layer A) уже маршрутизируется через этот канал, но card-фетч (Layer B) через camoufox на нём стабильно падает.

Вердикт: residential ASocks-порт прошёл connectivity-проверку, но НЕ подтверждён рабочим для реального Layer B card-фетча. Дальнейшая диагностика (сторона ASocks, логи их прокси-сервера, возможно другой тип порта/лимиты на browser-туннели vs plain HTTP) — вне возможностей агента. domclick_local_runner.py (ручной, домашний IP) остаётся единственным подтверждённо рабочим каналом. Issue остаётся open/needs-human.

## Финальный апдейт после обновления whitelist (2026-07-04) После того как юзер обновил IP-whitelist на ASocks-панели — базовая connectivity починилась: `curl -x <proxy> https://i.pn` с прод-VPS → успех, exit IP `185.181.247.139` (Moscow, `AS35048 Biterika Group LLC`, `mobile:false,proxy:false,hosting:false` — чистый residential-профиль). **НО реальный card-фетч через прод-браузер (`tradein-browser` camoufox, `POST /fetch`) — 3/3 попытки провалены**: 1× `TimeoutError: Page.goto Timeout 60000ms`, 2× `Error: Page.goto: NS_ERROR_PROXY_BAD_GATEWAY`. Это ошибка прокси-туннеля при браузерной навигации, НЕ QRATOR-ответ (до domclick запрос не доходит вообще) — при этом базовый curl через тот же прокси работает нормально. Технический контекст: DomClick намеренно falls through на `generic`-провайдера в `tradein-browser` (нет `BROWSER_PROXY_DOMCLICK`) → `SCRAPER_PROXY_URL` = именно этот ASocks-порт (`browser/server.py:551-553`). Т.е. serp-трафик (Layer A) уже маршрутизируется через этот канал, но card-фетч (Layer B) через camoufox на нём стабильно падает. **Вердикт**: residential ASocks-порт прошёл connectivity-проверку, но НЕ подтверждён рабочим для реального Layer B card-фетча. Дальнейшая диагностика (сторона ASocks, логи их прокси-сервера, возможно другой тип порта/лимиты на browser-туннели vs plain HTTP) — вне возможностей агента. `domclick_local_runner.py` (ручной, домашний IP) остаётся единственным подтверждённо рабочим каналом. Issue остаётся open/needs-human.

~~lekss361 referenced this issue 2026-07-04 16:37:46 +00:00~~

fix(tradein/domclick): органический заход через SERP перед card-fetch (anti-QRATOR) #2430

lekss361 referenced this issue

2026-07-04 16:38:30 +00:00

fix(tradein/domclick): органический заход через SERP перед card-fetch (anti-QRATOR) #2430

lekss361 commented

2026-07-04 16:38:47 +00:00

Author

Owner

Прогресс 2026-07-04:

Блокер («нужен dedicated residential RU proxy с чистой репутацией») снят. id=1 (scrape_proxies, ASocks residential 212.8.249.134:10423, provider_affinity='domclick') — после ротации IP через дашборд ASocks прод-smoke прошёл живьём: BrowserFetcher.fetch() на card-URL → HTTP 200, html_len=815705, __SSR_STATE__ присутствует полностью. QRATOR reputation-403 больше не срабатывает на этот IP.

Важный вывод по механике блокировки: дело было не в типе прокси/протоколе (HTTP vs SOCKS5 — параллельно тестировали, не влияет) и не в фингерпринте браузера — чисто репутация конкретного exit-IP, которую сжигают повторные пробы без прохождения challenge. Смена IP на чистый — надёжный, но временный фикс (IP снова "устаёт" через несколько часов активного тестирования).

Более сильный фикс, найден и смержен: PR #2430 (органический заход через same-site SERP перед card-фетчем) и PR #2433 (cookie-injection MVP) — эмпирически подтверждено, что инъекция cookies валидной аутентифицированной test-аккаунт сессии (Sber ID) полностью обходит QRATOR reputation-блок, даже на уже подозрительном/сожжённом прокси-IP. Это снимает зависимость от постоянной ротации IP.

Что смержено:

domclick_session_cookies (шифрованное хранение, зеркалит существующий cian_session_cookies)
POST /scrape/domclick/upload-cookies — ручная загрузка cookies test-аккаунта
POST /scrape/domclick/debug/detail-fetch — рабочий debug-путь: session→cookies→fetch_detail через выделенный source="domclick" прокси-пул
cookies-параметр в browser_fetcher.fetch()//fetch — провайдер-агностичный механизм (домен куки выводится из URL, не захардкожен), пригоден для будущего переиспользования другими провайдерами

Детали механики блокировки в vault meta/00_credentials.md.

Оставшийся объём issue:

Смержить dormant-ветку feat/tradein-domclick-detail-backfill (commit eef23071) — Layer B parser/orchestrator уже готов и протестирован там; при мерже подключить domclick_session.load_session() + cookies= в реальный оркестратор (сейчас только debug-эндпоинт использует cookie-injection).
UPDATE scrape_schedules SET enabled=true WHERE source='domclick_detail_backfill' после мержа.
Прод-smoke полного backfill-цикла с cookie-injection на масштабе (не только единичного card-фетча).
Периодическое обновление test-аккаунт cookies через /scrape/domclick/upload-cookies (нет пока auto-login/verify_session — MVP, будущее улучшение).

Issue оставляю open до выполнения этих пунктов.

Прогресс 2026-07-04: **Блокер («нужен dedicated residential RU proxy с чистой репутацией») снят.** id=1 (`scrape_proxies`, ASocks residential `212.8.249.134:10423`, `provider_affinity='domclick'`) — после ротации IP через дашборд ASocks прод-smoke прошёл живьём: `BrowserFetcher.fetch()` на card-URL → HTTP 200, html_len=815705, **`__SSR_STATE__` присутствует полностью**. QRATOR reputation-403 больше не срабатывает на этот IP. Важный вывод по механике блокировки: дело было не в типе прокси/протоколе (HTTP vs SOCKS5 — параллельно тестировали, не влияет) и не в фингерпринте браузера — чисто репутация конкретного exit-IP, которую сжигают повторные пробы без прохождения challenge. Смена IP на чистый — надёжный, но временный фикс (IP снова "устаёт" через несколько часов активного тестирования). **Более сильный фикс, найден и смержен:** PR #2430 (органический заход через same-site SERP перед card-фетчем) и **PR #2433 (cookie-injection MVP)** — эмпирически подтверждено, что инъекция cookies валидной аутентифицированной test-аккаунт сессии (Sber ID) **полностью обходит QRATOR reputation-блок, даже на уже подозрительном/сожжённом прокси-IP**. Это снимает зависимость от постоянной ротации IP. Что смержено: - `domclick_session_cookies` (шифрованное хранение, зеркалит существующий `cian_session_cookies`) - `POST /scrape/domclick/upload-cookies` — ручная загрузка cookies test-аккаунта - `POST /scrape/domclick/debug/detail-fetch` — рабочий debug-путь: session→cookies→fetch_detail через выделенный `source="domclick"` прокси-пул - `cookies`-параметр в `browser_fetcher.fetch()`/`/fetch` — провайдер-агностичный механизм (домен куки выводится из URL, не захардкожен), пригоден для будущего переиспользования другими провайдерами Детали механики блокировки в vault `meta/00_credentials.md`. **Оставшийся объём issue:** 1. Смержить dormant-ветку `feat/tradein-domclick-detail-backfill` (commit `eef23071`) — Layer B parser/orchestrator уже готов и протестирован там; при мерже подключить `domclick_session.load_session()` + `cookies=` в реальный оркестратор (сейчас только debug-эндпоинт использует cookie-injection). 2. `UPDATE scrape_schedules SET enabled=true WHERE source='domclick_detail_backfill'` после мержа. 3. Прод-smoke полного backfill-цикла с cookie-injection на масштабе (не только единичного card-фетча). 4. Периодическое обновление test-аккаунт cookies через `/scrape/domclick/upload-cookies` (нет пока auto-login/verify_session — MVP, будущее улучшение). Issue оставляю open до выполнения этих пунктов.

bot-backend referenced this issue from a commit

2026-07-04 17:46:28 +00:00

feat(tradein/domclick): cookie-injection MVP для обхода QRATOR-блока (#2000)

lekss361 referenced this issue

2026-07-04 17:46:42 +00:00

feat(tradein/domclick): cookie-injection MVP для обхода QRATOR-блока (#2000) #2433

lekss361 referenced this issue from a commit

2026-07-04 17:49:41 +00:00

feat(tradein/domclick): cookie-injection MVP для обхода QRATOR-блока (#2000) (#2433)

bot-backend referenced this issue from a commit

2026-07-04 19:46:37 +00:00

feat(tradein/domclick): production Layer B detail-backfill orchestrator (#2000)

lekss361 referenced this issue

2026-07-04 19:47:20 +00:00

feat(tradein/domclick): production Layer B detail-backfill orchestrator (#2000) #2436

lekss361 referenced this issue from a commit

2026-07-04 19:49:09 +00:00

feat(tradein/domclick): production Layer B detail-backfill orchestrator (#2000) (#2436)

lekss361 commented

2026-07-04 19:59:16 +00:00

Author

Owner

Прод-оркестратор задеплоен и верифицирован (2026-07-04, PR #2436)

Построен заново (не смёржен из dormant-ветки — та была удалена ранее сегодня как unmergeable, ссылалась на снесённый legacy app/services/scrapers/*). Новый app/tasks/domclick_detail_backfill.py мирроит avito_detail_backfill.py, cookie-injection подключена через domclick_session.load_session(db) в реальный (не debug) путь, deep-code-review APPROVE, задеплоено успешно (образы пересобраны 19:50:45 UTC, test/build-backend/deploy все green).

Верифицировано живьём после деплоя:

Новый файл domclick_detail_backfill.py присутствует в tradein-scraper.
Миграция 175 применена — scrape_schedules строка domclick_detail_backfill существует, enabled=false (как и планировалось — активация отдельный шаг).
Debug-эндпоинт (POST /scrape/domclick/debug/detail-fetch) на реальной карточке (sale__flat__2076121814) → HTTP 200, ok:true, полный detail (repair/area/priceHistory/AVM) — инфраструктура (proxy/SSRF-guard/browser-fetch) после деплоя здорова.

Блокер перед включением schedule: `domclick_session_cookies` пуста (0 строк)

Прямая проверка БД: таблица существует (миграция 174 применена), но ни одной валидной сессии сейчас нет. Живое тестирование cookie-injection в прошлой сессии, судя по всему, не сохранило сессию персистентно (или она с тех пор истекла/была инвалидирована — точная причина не установлена, но факт таков: SELECT count(*) FROM domclick_session_cookies → 0).

Без cookies включение schedule на реальном трафике будет полагаться ТОЛЬКО на резидентный прокси-IP (сейчас проходит — подтверждено выше единичным фетчем — но по всей истории этого issue репутация IP "устаёт" при устойчивой нагрузке без cookie-защиты). Учитывая, что бэклог на сегодня = 0 (все 6296 активных domklik-листингов уже обогащены через ручной domclick_local_runner.py в этой же сессии), включение schedule сейчас безопасно, но бессмысленно для реального смоука (обработает 0 строк) — а вот когда SERP-слой в ближайшие дни найдёт новые domklik-листинги, schedule начнёт реально бить по прокси без cookie-защиты.

Нужно (needs-human, не выполнимо агентом): залогиниться в DomClick тестовым аккаунтом (Sber ID) реальным браузером, извлечь cookies, загрузить через POST /scrape/domclick/upload-cookies. После этого:

UPDATE scrape_schedules SET enabled=true WHERE source='domclick_detail_backfill'
Дождаться реального backlog (новые domklik-листинги от SERP-слоя) или next_run_at=now() для форс-триггера
Прод-smoke полного цикла С cookie-injection на масштабе (cookies_injected=true в логах/heartbeat)

Оставляю enabled=false и issue open/needs-human до этого шага — не хочу жечь репутацию единственного выделенного прокси вхолостую.

## Прод-оркестратор задеплоен и верифицирован (2026-07-04, PR #2436) Построен заново (не смёржен из dormant-ветки — та была удалена ранее сегодня как unmergeable, ссылалась на снесённый legacy `app/services/scrapers/*`). Новый `app/tasks/domclick_detail_backfill.py` мирроит `avito_detail_backfill.py`, cookie-injection подключена через `domclick_session.load_session(db)` в реальный (не debug) путь, deep-code-review APPROVE, задеплоено успешно (образы пересобраны 19:50:45 UTC, `test`/`build-backend`/`deploy` все green). **Верифицировано живьём после деплоя:** - Новый файл `domclick_detail_backfill.py` присутствует в `tradein-scraper`. - Миграция 175 применена — `scrape_schedules` строка `domclick_detail_backfill` существует, `enabled=false` (как и планировалось — активация отдельный шаг). - Debug-эндпоинт (`POST /scrape/domclick/debug/detail-fetch`) на реальной карточке (`sale__flat__2076121814`) → `HTTP 200, ok:true`, полный detail (repair/area/priceHistory/AVM) — инфраструктура (proxy/SSRF-guard/browser-fetch) после деплоя здорова. ## Блокер перед включением schedule: `domclick_session_cookies` пуста (0 строк) Прямая проверка БД: таблица существует (миграция 174 применена), но **ни одной валидной сессии сейчас нет**. Живое тестирование cookie-injection в прошлой сессии, судя по всему, не сохранило сессию персистентно (или она с тех пор истекла/была инвалидирована — точная причина не установлена, но факт таков: `SELECT count(*) FROM domclick_session_cookies` → 0). Без cookies включение schedule на реальном трафике будет полагаться ТОЛЬКО на резидентный прокси-IP (сейчас проходит — подтверждено выше единичным фетчем — но по всей истории этого issue репутация IP "устаёт" при устойчивой нагрузке без cookie-защиты). Учитывая, что бэклог на сегодня = 0 (все 6296 активных `domklik`-листингов уже обогащены через ручной `domclick_local_runner.py` в этой же сессии), **включение schedule сейчас безопасно, но бессмысленно для реального смоука** (обработает 0 строк) — а вот когда SERP-слой в ближайшие дни найдёт новые domklik-листинги, schedule начнёт реально бить по прокси без cookie-защиты. **Нужно (needs-human, не выполнимо агентом):** залогиниться в DomClick тестовым аккаунтом (Sber ID) реальным браузером, извлечь cookies, загрузить через `POST /scrape/domclick/upload-cookies`. После этого: 1. `UPDATE scrape_schedules SET enabled=true WHERE source='domclick_detail_backfill'` 2. Дождаться реального backlog (новые domklik-листинги от SERP-слоя) или `next_run_at=now()` для форс-триггера 3. Прод-smoke полного цикла С cookie-injection на масштабе (`cookies_injected=true` в логах/heartbeat) Оставляю `enabled=false` и issue open/needs-human до этого шага — не хочу жечь репутацию единственного выделенного прокси вхолостую.

lekss361 commented

2026-07-04 20:13:24 +00:00

Author

Owner

Разрешено (2026-07-04, 20:11 UTC)

Пользователь залогинился в тестовый DomClick-аккаунт (Sber ID) реальным браузером и выгрузил cookies через /scrape/domclick/upload-cookies — accountCasId=58342708, 16 cookies прошли фильтр DOMCLICK_REQUIRED_COOKIES, сессия сохранена (валидна до 2026-08-03).

Живая проверка после загрузки:

Debug-фетч (sale__flat__2076121814) → cookies_injected: true (было false до загрузки, тот же прокси/тот же URL) — cookie-injection реально активна.
UPDATE scrape_schedules SET enabled=true, next_run_at=now() → scheduler tick в tradein-scraper подхватил ≤60с, scrape_runs id=709: status=done, attempted=0, failed=0, blocked=0 (backlog сегодня = 0, все текущие domklik-листинги уже обогащены вручную ранее в этой сессии — так что 0 attempted ожидаемо, не ошибка; проверяет именно dispatch-плюмбинг, который подтверждён рабочим end-to-end).

Итоговое состояние: DomClick Layer B полностью в проде — оркестратор задеплоен (PR #2436), schedule включён, cookie-сессия загружена и подтверждена рабочей. Когда SERP-слой найдёт новые domklik-листинги (окно 15-18 UTC, ежедневно), backfill будет обрабатывать их автоматически с cookie-injection защитой от QRATOR.

Оставшийся операционный момент (не блокер, задокументированное MVP-ограничение): сессия истекает 2026-08-03 — потребуется повторная ручная загрузка cookies через тот же эндпоинт (нет auto-login/verify_session, см. POST /scrape/domclick/upload-cookies докстринг).

Закрываю issue.

## Разрешено (2026-07-04, 20:11 UTC) Пользователь залогинился в тестовый DomClick-аккаунт (Sber ID) реальным браузером и выгрузил cookies через `/scrape/domclick/upload-cookies` — `accountCasId=58342708`, 16 cookies прошли фильтр `DOMCLICK_REQUIRED_COOKIES`, сессия сохранена (валидна до 2026-08-03). **Живая проверка после загрузки:** - Debug-фетч (`sale__flat__2076121814`) → `cookies_injected: true` (было `false` до загрузки, тот же прокси/тот же URL) — cookie-injection реально активна. - `UPDATE scrape_schedules SET enabled=true, next_run_at=now()` → scheduler tick в `tradein-scraper` подхватил ≤60с, `scrape_runs` id=709: `status=done, attempted=0, failed=0, blocked=0` (backlog сегодня = 0, все текущие domklik-листинги уже обогащены вручную ранее в этой сессии — так что 0 attempted ожидаемо, не ошибка; проверяет именно dispatch-плюмбинг, который подтверждён рабочим end-to-end). **Итоговое состояние:** DomClick Layer B полностью в проде — оркестратор задеплоен (PR #2436), schedule включён, cookie-сессия загружена и подтверждена рабочей. Когда SERP-слой найдёт новые domklik-листинги (окно 15-18 UTC, ежедневно), backfill будет обрабатывать их автоматически с cookie-injection защитой от QRATOR. **Оставшийся операционный момент (не блокер, задокументированное MVP-ограничение):** сессия истекает 2026-08-03 — потребуется повторная ручная загрузка cookies через тот же эндпоинт (нет auto-login/verify_session, см. `POST /scrape/domclick/upload-cookies` докстринг). Закрываю issue.

lekss361 closed this issue

2026-07-04 20:13:25 +00:00