scraper_kit.providers.cian.valuation.estimate_via_cian_valuation (and
session.load_session) already existed with mandatory config: ScraperConfig
(no default) — this was ground prepared ahead of Group E2, not new work here.
This change proves it's safe to switch estimator.py's import to it (#2337):
- Extends the existing _parse_valuation_state golden-parity test with a
full-pipeline parity test (cache-miss -> load_session -> curl_cffi fetch ->
extract_state -> auth-check -> parse -> sanity-check), wired with
config=RealScraperConfig() per the #2306 convention
(app/services/cian_price_history.py).
- Adds a regression guard proving estimate_via_cian_valuation raises TypeError
when config= is omitted, and documents why that must stay mandatory:
estimator.py's call site (line ~3143) sits inside a blanket
`except Exception` that only does `logger.warning(..., exc)` (no exc_info,
no logger.exception) -- below GlitchTip's ERROR-level capture threshold
(see LoggingIntegration(event_level=logging.ERROR) in app/main.py), so a
TypeError from a missing config= would be logged but invisible in
GlitchTip/Sentry, indistinguishable from ordinary graceful degradation.
- Documents an asymmetry vs. the task's initial assumption: kit's
load_session requires config= mandatorily, but mark_session_invalid does
NOT take a config parameter at all (confirmed by inspection, not a
footgun -- just noting the actual contract).
- Confirms app/services/estimator.py is not the only real caller:
app/tasks/cian_history_backfill.py also imports estimate_via_cian_valuation
directly and deliberately stays on the legacy import for now (see its own
comment referencing issue #2308) -- out of scope for this change, flagged
for whoever picks up cian_history_backfill's migration.
Full backend test suite: 3211 passed, 6 skipped, 1 pre-existing unrelated
failure (test_search_api.py::test_search_cache_hit, 401 vs 200 auth issue,
reproduces identically on main without this change).
