[tradein][scrapers] /fetch-json: тюнинг settle после навигации (транзиентный NetworkError на первом XHR) #1917

New issue

Closed

opened 2026-06-26 10:24:32 +00:00 by bot-backend · 1 comment

bot-backend commented

2026-06-26 10:24:32 +00:00

Collaborator

Follow-up из #915 Stage 2/3.

Симптом

На прод-валидации IMV-через-браузер (2026-06-26): первый XHR после навигации на origin (/evaluation/realty) иногда падает с Page.evaluate: NetworkError when attempting to fetch resource. Один retry (на уровне BrowserFetcher.fetch_json или IMV-флоу) лечит — eval успешно завершается (house 12897 → ok, rec 12.37M). Но retry добавляет ~30-45с на дом.

Гипотеза

_fetch_json_once (browser/server.py) после page.goto(origin, wait_until="domcontentloaded") ждёт только 500мс перед page.evaluate(fetch). Для avito этого мало — anti-bot / сетевой стек страницы ещё не готов → первый fetch() ловит NetworkError.

Что сделать (low-pri)

Поднять settle для /fetch-json (напр. 1500-2500мс) ИЛИ сделать in-page retry самого fetch() (1 повтор с паузой) внутри page.evaluate, ИЛИ wait_until="networkidle" для fetch-json-ветки.
Замерить: доля coords-запросов, проходящих с первого раза, до/после.
Не трогать /fetch (SERP) — там своя BROWSER_WAIT_MS=6000.

Зачем

Ускорит ночной house_imv_backfill (~9.7k pending-домов, #562) — сейчас каждый дом может тратить лишний retry-цикл. Корректность уже есть (retry лечит), это перф.

Refs #915, #562. scope/backend, scrapers, priority/p3.

Follow-up из #915 Stage 2/3. ## Симптом На прод-валидации IMV-через-браузер (2026-06-26): первый XHR после навигации на origin (`/evaluation/realty`) иногда падает с `Page.evaluate: NetworkError when attempting to fetch resource`. Один retry (на уровне `BrowserFetcher.fetch_json` или IMV-флоу) лечит — eval успешно завершается (house 12897 → ok, rec 12.37M). Но retry добавляет ~30-45с на дом. ## Гипотеза `_fetch_json_once` (browser/server.py) после `page.goto(origin, wait_until="domcontentloaded")` ждёт только **500мс** перед `page.evaluate(fetch)`. Для avito этого мало — anti-bot / сетевой стек страницы ещё не готов → первый `fetch()` ловит NetworkError. ## Что сделать (low-pri) - Поднять settle для `/fetch-json` (напр. 1500-2500мс) ИЛИ сделать in-page retry самого `fetch()` (1 повтор с паузой) внутри `page.evaluate`, ИЛИ `wait_until="networkidle"` для fetch-json-ветки. - Замерить: доля coords-запросов, проходящих с первого раза, до/после. - Не трогать `/fetch` (SERP) — там своя BROWSER_WAIT_MS=6000. ## Зачем Ускорит ночной `house_imv_backfill` (~9.7k pending-домов, #562) — сейчас каждый дом может тратить лишний retry-цикл. Корректность уже есть (retry лечит), это перф. Refs #915, #562. scope/backend, scrapers, priority/p3.

bot-backend added the

labels 2026-06-26 13:28:34 +00:00

Light1YT referenced this issue from a commit

2026-06-27 00:30:21 +00:00

fix(tradein-browser): in-page fetch retry + configurable settle for /fetch-json (#1917)

bot-backend referenced this issue

2026-06-27 00:30:41 +00:00

fix(tradein-browser): in-page fetch retry + settle tuning for /fetch-json (#1917) #1938

bot-backend referenced this issue from a commit

2026-06-27 00:31:22 +00:00

Merge pull request 'fix(tradein-browser): in-page fetch retry + settle tuning for /fetch-json (#1917)' (#1938) from fix/1917-fetch-json-network-retry into main

bot-backend commented

2026-06-27 00:36:24 +00:00

Author

Collaborator

✅ Задеплоено + проверено live (2026-06-27)

PR #1938 смержен + задеплоен (browser-образ пересобран, tradein-browser Up на свежем образе, healthy).

Фикс (efficient — in-page retry вместо outer re-navigation):

_fetch_json_once: settle 500 → FETCH_JSON_SETTLE_MS (default 1200мс) — меньше first-fails.
In-page JS-retry самого fetch(): повтор ТОЛЬКО при сетевом throw (NetworkError), НЕ при HTTP-статусе (4xx/5xx short-circuit). FETCH_JSON_INPAGE_RETRIES=1, FETCH_JSON_RETRY_DELAY_MS=800. Повтор внутри страницы ~0.8с против ~30-45с полной ре-навигации.
/fetch (SERP) не тронут.

Verify на проде: код live в контейнере (FETCH_JSON_SETTLE_MS + throw lastErr в /app/server.py), env-override нет → дефолты 1200/1/800 в силе. code-reviewer ✅ APPROVE (retry network-only, caller-compat, crash-retry intact). 11 browser-тестов (9+2).

Эмпирика (доля coords-запросов с первого раза до/после) проявится в логах ночного house_imv_backfill (#562) — теперь и в scrape_runs.total_seen (хардинг #1928/#1926). Если retry-цикл не понадобится — увидим по attempts:1.

Корректность была и раньше (внешний retry лечил); это perf. Закрываю — фикс шипнут и подтверждён live.

## ✅ Задеплоено + проверено live (2026-06-27) PR #1938 смержен + задеплоен (browser-образ пересобран, `tradein-browser` Up на свежем образе, healthy). **Фикс (efficient — in-page retry вместо outer re-navigation):** - `_fetch_json_once`: settle `500 → FETCH_JSON_SETTLE_MS` (default **1200мс**) — меньше first-fails. - In-page JS-retry самого `fetch()`: повтор ТОЛЬКО при сетевом throw (NetworkError), НЕ при HTTP-статусе (4xx/5xx short-circuit). `FETCH_JSON_INPAGE_RETRIES=1`, `FETCH_JSON_RETRY_DELAY_MS=800`. Повтор внутри страницы ~0.8с против ~30-45с полной ре-навигации. - `/fetch` (SERP) не тронут. **Verify на проде:** код live в контейнере (`FETCH_JSON_SETTLE_MS` + `throw lastErr` в `/app/server.py`), env-override нет → дефолты 1200/1/800 в силе. code-reviewer ✅ APPROVE (retry network-only, caller-compat, crash-retry intact). 11 browser-тестов (9+2). **Эмпирика** (доля coords-запросов с первого раза до/после) проявится в логах ночного `house_imv_backfill` (#562) — теперь и в `scrape_runs.total_seen` (хардинг #1928/#1926). Если retry-цикл не понадобится — увидим по `attempts:1`. Корректность была и раньше (внешний retry лечил); это perf. Закрываю — фикс шипнут и подтверждён live.

bot-backend closed this issue

2026-06-27 00:36:29 +00:00

bot-backend referenced this issue from a commit

2026-07-04 16:37:27 +00:00

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