Round-2 review (MAJOR) left three items open:
1. cap_mult was threaded through as a jsonb default_params parameter but never
validated, reproducing the exact ttl_days<=0 hole the earlier guard closed.
Verified live: cap_mult=0 -> effective_ttl=0 -> whole active pool of the
source would deactivate; cap_mult=0.5 pushes the ceiling BELOW the operator-
configured ttl_days. Added `if cap_mult < 1: raise ValueError` next to the
ttl_days guard (same fail-fast contract, before any SQL). Non-numeric values
(e.g. a stringly-typed "6" from a typo in default_params) already fail safe
via TypeError on the comparison, caught by the same except-block -> mark_failed.
Covered with 5 new tests (zero/negative/<1/non-numeric/mark_failed routing).
2. The mechanical part of cap_mult (parameter + wiring) was merged but never
calibrated for avito on prod -- no migration shipped, so prod default_params
for deactivate_stale_avito still lacked "cap_mult" and ran with the module
default (CAP_MULT=2, ceiling=20d), which is BELOW avito's own p99 revisit gap
(42.1d) and below the observed prod peak (floor=52, three runs 08-10..08-12).
Added data/sql/264_deactivate_stale_avito_cap_mult.sql (idempotent, same
pattern as 219) setting cap_mult=6 for deactivate_stale_avito only (ceiling
60d, matching the order of magnitude already used for cian/yandex). cian/
yandex/domklik keep the CAP_MULT=2 default -- their p99 gaps (26.6/43.0/3.1)
sit comfortably under their default ceilings (60/60/28), no override needed.
Pinned the calibration with a dedicated test
(test_avito_prod_floor_is_capped_by_calibrated_cap_mult) instead of leaving
the avito slice skipped in the false-kill coverage test.
3. Confirmed (SSH read-only, prod counts): active rows aged >60d that this PR
cannot touch regardless of cap_mult -- cian/novostroyki 9483, cian/NULL
211, yandex/NULL 523 (0 inside the jobs' actual scope: cian/vtorichka,
yandex/vtorichka). deactivate_stale_cian/_yandex are scoped to
segments=['vtorichka'] by a deliberate, documented DECISION (blanket TTL on
novostroyki risks killing live inventory cian/yandex don't fully sweep).
Widening that scope is a separate, riskier investigation and is out of
scope here -- documented the gap directly in the module docstring next to
the existing DECISION so it isn't lost.
Verification (SSH read-only against prod, 2026-08-15): recomputed the exact
per-source formula the next scheduled run will use. In-scope next-run
deactivation is currently 0 for all four sources -- the active pool has
already self-corrected to be consistent with each source's own recent
effective TTL (yesterday's yandex run used effective=54, so no active row is
older than that yet). This matches the round-2 reviewer's own conclusion: the
cap is a preventative guardrail, not a retroactive cleanup, and isn't expected
to fire on the exact day it's calibrated. It is not idle, though -- live
recompute of yandex/vtorichka's raw (uncapped) floor right now is 78.2d,
already above its 60d ceiling; the trailing 6-day counters show the identical
loop (floor=75, deactivated=0, three days straight) already recurred twice
without this cap in place. The mechanism will bind the moment the pool ages
past the ceiling, which is exactly the recurrence it exists to stop.
Tests: 106 passed (test_deactivate_stale_ttl_cap.py,
test_deactivate_stale_revisit_floor.py, test_deactivate_stale_health_gate.py,
test_deactivate_stale_listings.py, test_migrations_manifest.py). ruff clean.
scripts/check-migration-lock-timeout.py: pass (UPDATE-only migration, no
blocking DDL, no SET LOCAL needed).
772ae116b5