fix(tradein): yandex combos watchdog timeout (P0) + deploy scraper filter gap #1659
No reviewers
Labels
No labels
admin
analytics
auth
automation
bug
business
chore
ci
compliance
data
data-moat
docs
duplicate
dx
enhancement
Fable 5 ревью
feedback/max
generative
GG-форсайт
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
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lekss361/gendesign#1659
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "fix/yandex-combos-watchdog-and-deploy-filter"
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?
Summary
Fixes a P0 regression introduced by #1658 + the deploy gap that hid it.
A — combos watchdog timeout (P0)
#1658 made
run_yandex_city_sweepdo 30 rooms×price combos in a single "center anchor", but the per-anchor watchdogasyncio.wait_for(..., timeout=ANCHOR_TIMEOUT_SEC=240)was sized for ONE quick geographic anchor. 30 combos × 3 pages × ~9s delay ≈ 18-30 min ≫ 240s → timed out mid-sweep, partial results discarded → lots_fetched=0 (prod-confirmed, worse than the old ~23-50).Fix: compute the watchdog timeout from the combos workload —
max(240, num_combos × max_pages × (request_delay + 12) + 300)≈ 2190s (~37min) for the default 30-combo config (fits the 02:00-05:00 window). Explicit-anchor mode (tests) keeps 240s/anchor.B — deploy scraper filter gap
deploy-tradein.yml'sscraperpath filter coveredscrapers/**,scheduler.py,tasks/**but notscrape_pipeline.py— even though the scheduler (tradein-scraper container) runsrun_*_city_sweepfrom it. So #1658's deploy didn't recreate the scraper → scheduler ran stale code until manual recreate. Addedscrape_pipeline.pyto the filter. Self-applying: this PR touches bothscrape_pipeline.pyand the filter, so its own deploy recreates the scraper.Test plan
Refs #1658, #759
Deep review APPROVE (sha
ed4662e3).Gate: ruff clean on changed files (2 pre-existing B011 in test_cadastral_reverse.py are on main, not touched here); pytest 1844 passed / 2 deselected / 0 fail; both new watchdog tests pass.
Correctness: combos-aware watchdog budget (~1560s prod 2-page, ~2190s 3-page) replaces the fixed 240s that killed the #1658 sweep at lots_fetched=0. Explicit-anchor/legacy path keeps ANCHOR_TIMEOUT_SEC=240. Inner per-request curl subprocess is independently bounded (wait_for timeout+10) so no infinite hang; budget fits the 02:00-05:00 window with wide margin.
Deploy: scrape_pipeline.py added to the scraper change-filter -> SCRAPER_CHANGED=true ->
up -d --no-deps scraper, so the tradein-scraper container gets the new sweep code this deploy (fixes the stale-code gotcha). Self-applying for this PR.Minor (non-blocking): timeout budget uses the param request_delay_sec (default 9.0) while the scraper's actual per-page sleep is get_scraper_delay('yandex') from DB; if an operator raises the DB delay well above 9s the budget could under-estimate. Strictly better than the prior hardcoded 240s.