lekss361/gendesign

Fork 0

[HIGH] tradein/proxy: браузерная проба спрашивает только Авито — узел «здоров» и мёртв для Домклика одновременно #2800

New issue

Closed

opened 2026-08-09 17:36:36 +00:00 by bot-backend · 3 comments

bot-backend commented

2026-08-09 17:36:36 +00:00

Collaborator

Найдено при разборе #2657 (обвал Домклика). Замеры с прода 2026-08-09.

Симптом: узел выглядит здоровым и мёртв одновременно

id | affinity | enabled | consecutive_fails | browser_fail_streak | браузер-проба | последний успех
 1 | domclick | t       |         0         |          0          | 08-09 13:41   | 08-09 17:11

Все счётчики зелёные. При этом живая проба тем же сайдкаром, на тот же URL Домклика:

узел	результат
id=1 residential (`affinity='domclick'`)	500 `NS_ERROR_PROXY_BAD_GATEWAY`
id=10 mobile (`affinity='any'`)	200, `{"offersCount":704,"snippetsCount":678}`

Узел, закреплённый специально за Домкликом, для Домклика не работает. Узел общего назначения — работает.

Цена: domclick_city_sweep даёт ноль лотов четвёртые сутки (09.08, 08.08, 07.08, 06.08 — все по 0), max(scraped_at) у источника — 05.08 05:43.

Причина: проба разделяет тракт, но не назначение

_HEALTH_PROBE_URL после #2736 ходит браузером — тракт починен, это была суть #2723. Но ходит он для всех узлов на https://www.avito.ru/robots.txt.

Прокси-узел — это не «жив/мёртв» вообще, а пара «узел × площадка». Авито пускает, Домклик отбивает — и наоборот. Проба, спрашивающая только Авито, отвечает на вопрос, которого не задавали, и её зелёный ответ читается как «узел годен», хотя годен он ровно для одной площадки из четырёх.

Понятие пары в системе уже есть: таблица scrape_proxy_source_bans (#2654) и колонка provider_affinity. Проба про него не знает.

Почему это не повтор #2723, а его продолжение

#2723 нашёл, что проба ходит другим транспортом, чем работа (HTTP против браузера), и это починили. Здесь проба ходит верным транспортом, но не туда. Один и тот же класс ошибки — «проба не проходит рабочим путём» — на другой оси.

Признак, по которому это ловится: счётчики отказов у узла нулевые, а работа на нём валится. Именно так 480 зелёных проб сосуществовали с 40 реальными отказами в #2723; здесь — свежая проба и browser_fail_streak=0 при стопроцентном отказе свипа.

Что предлагается

Немедленное, размером в миграцию: scrape_proxies.id=1 — снять provider_affinity='domclick'. Сейчас эта настройка резервирует под Домклик узел, для Домклика мёртвый, и прячет его от остальных источников, которым он, возможно, годен. Ставить 'any' (тогда решает проба) либо enabled=false (если он мёртв везде — проверить). После PR #2796 код это переживает: узел выдаётся, падает, lease ротируется, consecutive_fails со временем отключит — но первый бакет каждого прогона тратится впустую.
По существу: проба на пару «узел × источник». Ходить не на один зашитый URL, а на лёгкую страницу каждой площадки, из которых узел обслуживает хотя бы одну; результат писать в разрезе источника (scrape_proxy_source_bans для этого уже есть). Тогда acquire(source=...) перестанет выдавать узел, зелёный по чужой площадке.
Осторожно с ценой: четыре узла × четыре источника = 16 проб за такт вместо 4. Проба должна быть дешёвой (robots.txt или аналог), а расписание — разреженным. Не превращать диагностику в нагрузку, из-за которой нас забанят.

Чего НЕ делать

Не «чинить» это, повысив порог отключения или сняв affinity у всех — это уберёт симптом и оставит слепоту. И не считать зелёную пробу доказательством: пока она про одну площадку, её зелёный означает «годен для Авито», не более.

Связано: #2723 (тракт пробы), #2654 (таблица пар), #2657 (обвал, на котором нашлось), #2638 (владелец: токен ASOCKS).

Найдено при разборе #2657 (обвал Домклика). Замеры с прода 2026-08-09. ## Симптом: узел выглядит здоровым и мёртв одновременно ``` id | affinity | enabled | consecutive_fails | browser_fail_streak | браузер-проба | последний успех 1 | domclick | t | 0 | 0 | 08-09 13:41 | 08-09 17:11 ``` Все счётчики зелёные. При этом живая проба **тем же сайдкаром, на тот же URL Домклика**: | узел | результат | |---|---| | id=1 residential (`affinity='domclick'`) | **500** `NS_ERROR_PROXY_BAD_GATEWAY` | | id=10 mobile (`affinity='any'`) | **200**, `{"offersCount":704,"snippetsCount":678}` | Узел, закреплённый **специально за Домкликом**, для Домклика не работает. Узел общего назначения — работает. Цена: `domclick_city_sweep` даёт **ноль лотов четвёртые сутки** (09.08, 08.08, 07.08, 06.08 — все по 0), `max(scraped_at)` у источника — 05.08 05:43. ## Причина: проба разделяет тракт, но не назначение `_HEALTH_PROBE_URL` после #2736 ходит **браузером** — тракт починен, это была суть #2723. Но ходит он для **всех** узлов на `https://www.avito.ru/robots.txt`. Прокси-узел — это не «жив/мёртв» вообще, а **пара «узел × площадка»**. Авито пускает, Домклик отбивает — и наоборот. Проба, спрашивающая только Авито, отвечает на вопрос, которого не задавали, и её зелёный ответ читается как «узел годен», хотя годен он ровно для одной площадки из четырёх. Понятие пары в системе **уже есть**: таблица `scrape_proxy_source_bans` (#2654) и колонка `provider_affinity`. Проба про него не знает. ## Почему это не повтор #2723, а его продолжение #2723 нашёл, что проба ходит **другим транспортом**, чем работа (HTTP против браузера), и это починили. Здесь проба ходит верным транспортом, но **не туда**. Один и тот же класс ошибки — «проба не проходит рабочим путём» — на другой оси. Признак, по которому это ловится: **счётчики отказов у узла нулевые, а работа на нём валится**. Именно так 480 зелёных проб сосуществовали с 40 реальными отказами в #2723; здесь — свежая проба и `browser_fail_streak=0` при стопроцентном отказе свипа. ## Что предлагается 1. **Немедленное, размером в миграцию:** `scrape_proxies.id=1` — снять `provider_affinity='domclick'`. Сейчас эта настройка резервирует под Домклик узел, для Домклика мёртвый, **и прячет его от остальных источников**, которым он, возможно, годен. Ставить `'any'` (тогда решает проба) либо `enabled=false` (если он мёртв везде — проверить). После PR #2796 код это переживает: узел выдаётся, падает, lease ротируется, `consecutive_fails` со временем отключит — но первый бакет каждого прогона тратится впустую. 2. **По существу:** проба на пару «узел × источник». Ходить не на один зашитый URL, а на лёгкую страницу **каждой** площадки, из которых узел обслуживает хотя бы одну; результат писать в разрезе источника (`scrape_proxy_source_bans` для этого уже есть). Тогда `acquire(source=...)` перестанет выдавать узел, зелёный по чужой площадке. 3. **Осторожно с ценой:** четыре узла × четыре источника = 16 проб за такт вместо 4. Проба должна быть дешёвой (robots.txt или аналог), а расписание — разреженным. Не превращать диагностику в нагрузку, из-за которой нас забанят. ## Чего НЕ делать Не «чинить» это, повысив порог отключения или сняв affinity у всех — это уберёт симптом и оставит слепоту. И не считать зелёную пробу доказательством: пока она про одну площадку, её зелёный означает «годен для Авито», не более. Связано: #2723 (тракт пробы), #2654 (таблица пар), #2657 (обвал, на котором нашлось), #2638 (владелец: токен ASOCKS).

bot-backend referenced this issue

2026-08-09 17:38:01 +00:00

[HIGH] tradein/scraper: охват Домклика упал в 8-10 раз — прод-свип даёт ~1% предложения, а видимый пул держался внешним ручным ингестом #2657

Light1YT referenced this issue from a commit

2026-08-09 17:56:41 +00:00

fix(tradein/proxy): узел, зарезервированный за Домкликом, до Домклика не доходит (#2800 A)

bot-backend referenced this issue

2026-08-09 17:57:13 +00:00

fix(tradein/proxy): узел, зарезервированный за Домкликом, до Домклика не доходит (#2800 A) #2802

Light1YT referenced this issue from a commit

2026-08-09 18:12:42 +00:00

fix(tradein/proxy): проба спрашивает каждую площадку, вердикт пишется на пару «узел × источник» (#2800 B)

bot-backend referenced this issue

2026-08-09 18:13:30 +00:00

fix(tradein/proxy): проба спрашивает каждую площадку, вердикт пишется на пару «узел × источник» (#2800 B) #2803

bot-backend referenced this issue from a commit

2026-08-09 18:15:57 +00:00

fix(tradein/proxy): узел, зарезервированный за Домкликом, до Домклика не доходит (#2800 A) (#2802)

bot-backend referenced this issue from a commit

2026-08-09 18:28:39 +00:00

fix(tradein/proxy): проба спрашивает каждую площадку, вердикт пишется на пару «узел × источник» (#2800 B) (#2803)

bot-backend commented

2026-08-09 18:45:39 +00:00

Author

Collaborator

Уточнение к формулировке в PR #2803 (пишу сам, пока не прочли как гарантию)

В теле PR сказано: «бан, распознанный боевым сбором, проба не гасит». Точнее так: проба не удаляет строку, помеченную reason='banned:*' — фильтр only_reason в clear_source_bans это обеспечивает, и на проде это уже видно (см. ниже).

Чего фильтр НЕ закрывает: если проба по той же паре сначала упадёт, mark_banned(..., reason='probe:browser') уходит в ON CONFLICT DO UPDATE и перезаписывает reason существующей строки. С этого момента строка считается «своей», и следующая зелёная проба её снимет. Узкий, но реальный сценарий: площадка отдаёт robots.txt, но капчит выдачу → проба зеленеет и возвращает узел источнику раньше времени.

Пока не чиню (отдельная правка, не в горячем PR). Варианты: не трогать reason в ветке DO UPDATE, если он уже не пробин, либо хранить владельца отдельной колонкой. Первый вариант — одна строка в SQL.

Прод-верификация #2803, прогон healthcheck 18:43:52Z

healthcheck done — reaped=0 checked=4 ok=4 failed=0 revived=0 bans_purged=0
  browser_checked=1 browser_ok=1 browser_unfit=0 browser_refit=0
  pair_checked=4 pair_banned=0 pair_cleared=0

Крест получил узел 9 (единственный, у кого browser_check_at старше 360 мин): 4 площадки, все зелёные, последняя — bff-search-web.domclick.ru (html_len=150, ровно как в живом замере).

pair_cleared=0 — это и есть проверка фильтра на живых данных: у узла 9 висят чужие строки (9,'avito','banned:avito') и (9,'cian','banned:cian'), проба по обеим площадкам прошла успешно и ни одну не сняла.

Узел 1 (тот, ради которого задача) в этот такт не попал: browser_check_at=13:41:17Z, порог 360 мин → его очередь в прогоне ~19:42Z. Критерий на него записан в PR до факта — жду.

### Уточнение к формулировке в PR #2803 (пишу сам, пока не прочли как гарантию) В теле PR сказано: «бан, распознанный боевым сбором, проба не гасит». Точнее так: **проба не удаляет строку, помеченную `reason='banned:*'`** — фильтр `only_reason` в `clear_source_bans` это обеспечивает, и на проде это уже видно (см. ниже). Чего фильтр НЕ закрывает: если проба по той же паре сначала **упадёт**, `mark_banned(..., reason='probe:browser')` уходит в `ON CONFLICT DO UPDATE` и **перезаписывает `reason`** существующей строки. С этого момента строка считается «своей», и следующая зелёная проба её снимет. Узкий, но реальный сценарий: площадка отдаёт robots.txt, но капчит выдачу → проба зеленеет и возвращает узел источнику раньше времени. Пока не чиню (отдельная правка, не в горячем PR). Варианты: не трогать `reason` в ветке `DO UPDATE`, если он уже не пробин, либо хранить владельца отдельной колонкой. Первый вариант — одна строка в SQL. ### Прод-верификация #2803, прогон healthcheck 18:43:52Z ``` healthcheck done — reaped=0 checked=4 ok=4 failed=0 revived=0 bans_purged=0 browser_checked=1 browser_ok=1 browser_unfit=0 browser_refit=0 pair_checked=4 pair_banned=0 pair_cleared=0 ``` Крест получил узел 9 (единственный, у кого `browser_check_at` старше 360 мин): 4 площадки, все зелёные, последняя — `bff-search-web.domclick.ru` (`html_len=150`, ровно как в живом замере). `pair_cleared=0` — это и есть проверка фильтра на живых данных: у узла 9 висят **чужие** строки `(9,'avito','banned:avito')` и `(9,'cian','banned:cian')`, проба по обеим площадкам прошла успешно и **ни одну не сняла**. Узел 1 (тот, ради которого задача) в этот такт не попал: `browser_check_at=13:41:17Z`, порог 360 мин → его очередь в прогоне ~19:42Z. Критерий на него записан в PR до факта — жду.

bot-backend commented

2026-08-09 19:54:10 +00:00

Author

Collaborator

Прод-верификация после деплоя обеих частей + две поправки к предпосылкам

Часть A (#2802). Миграция 253 применена 18:21:19Z, scrape_proxies.id=1 → provider_affinity='any'. Критерий «узел начинает доставаться другим источникам» выполнен в 18:52:29Z:

proxy_pool: leased proxy id=1 provider=yandex by=-1

До миграции такой строки быть не могло: acquire('yandex') фильтрует по provider_affinity IN ('yandex','any'), а fallback узел не брал (защита последнего узла выделенной affinity).

Часть B (#2803). Первый крест — узел 9, прогон 18:43:52Z, pair_checked=4 pair_banned=0 pair_cleared=0. Ноль снятых — это и есть проверка фильтра only_reason на живых данных: у узла 9 висят ЧУЖИЕ строки banned:avito и banned:cian, проба по обеим площадкам прошла зелено и ни одну не тронула.

Второй крест — узел 1, прогон 19:43-19:44Z:

pair probe FAILED id=1 source=cian (fail_kind=page): not robots.txt (html_len=374168):
  <!DOCTYPE html><html lang="ru">… — пишем бан пары
healthcheck done — … browser_checked=1 browser_ok=1 browser_unfit=0 …
  pair_checked=4 pair_banned=1 pair_cleared=0

Раздельные вердикты по источникам у одного узла получены: Циан отбракован, узел остался годным остальным, browser_unfit_since пуст. Старая проба этот отказ не видела вообще — Циан отдаёт заглушку с кодом 200 и непустым телом.

Поправка 1: пара «узел 1 × Домклик» не мертва, она МИГАЕТ

Три замера одного и того же:

время	`domclick.ru/robots.txt`	`bff-search-web.domclick.ru/robots.txt`
~17:55Z (мой первый крест)	200	500 `NS_ERROR_PROXY_BAD_GATEWAY`
19:44:16Z (боевой healthcheck)	—	200 (`html_len=150`) → бан не записан
19:50Z (мой повторный крест)	500	500

То есть предпосылка «узел 1 мёртв для Домклика» верна не всегда, и мой же довод «apex отвечает 200, а рабочий хост нет» держался ровно на моменте замера: в 19:50 apex тоже отдал 500. Выбор рабочего хоста для пробы от этого не перестаёт быть правильным (спрашивать надо то, куда ходит сбор), но обосновывать его различием apex/bff как СТАБИЛЬНЫМ свойством — нельзя, снимаю.

Следствие для схемы: такт 360 мин на мигающей паре даёт вердикт, который может врать в обе стороны. Пока считаю приемлемым (бан 6 ч, зелёная проба снимает его следующим тактом), но это названный потолок, а не «покрыто».

Поправка 2: перезапись `reason` подтвердилась на проде — ровно как написано часом раньше

Строка (1,'cian') до креста: reason='banned:cian', ban_count=1. После: reason='probe:browser', ban_count=2, banned_until=10.08 07:43Z. То есть проба, упав по паре, забирает чужую строку себе, и следующая зелёная проба её снимет — при том что бан её писал боевой сбор.

Фикс на одну строку в mark_banned (ветка ON CONFLICT DO UPDATE):

reason = CASE WHEN scrape_proxy_source_bans.reason = CAST(:reason AS text)
                   OR scrape_proxy_source_bans.banned_until <= now()
              THEN CAST(:reason AS text)
              ELSE scrape_proxy_source_bans.reason END,

— владельца АКТИВНОЙ строки не меняем, истёкшую можно переприсвоить. Отдельным PR с красным тестом, не в горячем: обе части сегодня уже смержены и деплой-очередь занята.

Прочее из живых замеров (не чинил, фиксирую)

Одиночные NS_ERROR_PROXY_CONNECTION_REFUSED на ~5.5 с (против ~10 с у успеха) прилетают то на одном узле, то на другом и каждый раз по разной площадке: 11×cian в 17:55, 10×yandex и 11×cian в 19:50, при том что 11×cian в 19:14 боевой крест прошёл зелено. На стабильное свойство пары не похоже; мои кресты идут залпом через один инстанс camoufox параллельно с боевым сбором, так что это может быть и лимит провайдера на одновременные сессии — утверждать не берусь, замера, который бы это развёл, я не делал.

Осталось (дата и критерий записаны ДО факта)

domclick_city_sweep — 10.08 04:43:59Z (scrape_schedules.next_run_at). Проверяемое утверждение ровно одно: первый бакет не тратится на узел, который до площадки не доходит — в логах не должно быть leased proxy id=1 provider=domclick при активном бане пары. Что Домклик от этого соберётся — не обещаю, у него могут быть беды помимо узла.

### Прод-верификация после деплоя обеих частей + две поправки к предпосылкам **Часть A (#2802).** Миграция 253 применена 18:21:19Z, `scrape_proxies.id=1 → provider_affinity='any'`. Критерий «узел начинает доставаться другим источникам» выполнен в 18:52:29Z: ``` proxy_pool: leased proxy id=1 provider=yandex by=-1 ``` До миграции такой строки быть не могло: `acquire('yandex')` фильтрует по `provider_affinity IN ('yandex','any')`, а fallback узел не брал (защита последнего узла выделенной affinity). **Часть B (#2803).** Первый крест — узел 9, прогон 18:43:52Z, `pair_checked=4 pair_banned=0 pair_cleared=0`. Ноль снятых — это и есть проверка фильтра `only_reason` на живых данных: у узла 9 висят ЧУЖИЕ строки `banned:avito` и `banned:cian`, проба по обеим площадкам прошла зелено и ни одну не тронула. Второй крест — узел 1, прогон 19:43-19:44Z: ``` pair probe FAILED id=1 source=cian (fail_kind=page): not robots.txt (html_len=374168): <!DOCTYPE html><html lang="ru">… — пишем бан пары healthcheck done — … browser_checked=1 browser_ok=1 browser_unfit=0 … pair_checked=4 pair_banned=1 pair_cleared=0 ``` Раздельные вердикты по источникам у одного узла получены: Циан отбракован, узел остался годным остальным, `browser_unfit_since` пуст. Старая проба этот отказ не видела вообще — Циан отдаёт заглушку с кодом 200 и непустым телом. --- ### Поправка 1: пара «узел 1 × Домклик» не мертва, она МИГАЕТ Три замера одного и того же: | время | `domclick.ru/robots.txt` | `bff-search-web.domclick.ru/robots.txt` | |---|---|---| | ~17:55Z (мой первый крест) | **200** | 500 `NS_ERROR_PROXY_BAD_GATEWAY` | | 19:44:16Z (боевой healthcheck) | — | **200** (`html_len=150`) → бан не записан | | 19:50Z (мой повторный крест) | 500 | 500 | То есть предпосылка «узел 1 мёртв для Домклика» верна не всегда, и мой же довод «apex отвечает 200, а рабочий хост нет» держался ровно на моменте замера: в 19:50 apex тоже отдал 500. Выбор рабочего хоста для пробы от этого не перестаёт быть правильным (спрашивать надо то, куда ходит сбор), но обосновывать его различием apex/bff как СТАБИЛЬНЫМ свойством — нельзя, снимаю. Следствие для схемы: такт 360 мин на мигающей паре даёт вердикт, который может врать в обе стороны. Пока считаю приемлемым (бан 6 ч, зелёная проба снимает его следующим тактом), но это названный потолок, а не «покрыто». ### Поправка 2: перезапись `reason` подтвердилась на проде — ровно как написано часом раньше Строка `(1,'cian')` до креста: `reason='banned:cian', ban_count=1`. После: `reason='probe:browser', ban_count=2, banned_until=10.08 07:43Z`. То есть проба, упав по паре, **забирает чужую строку себе**, и следующая зелёная проба её снимет — при том что бан её писал боевой сбор. Фикс на одну строку в `mark_banned` (ветка `ON CONFLICT DO UPDATE`): ```sql reason = CASE WHEN scrape_proxy_source_bans.reason = CAST(:reason AS text) OR scrape_proxy_source_bans.banned_until <= now() THEN CAST(:reason AS text) ELSE scrape_proxy_source_bans.reason END, ``` — владельца АКТИВНОЙ строки не меняем, истёкшую можно переприсвоить. Отдельным PR с красным тестом, не в горячем: обе части сегодня уже смержены и деплой-очередь занята. ### Прочее из живых замеров (не чинил, фиксирую) Одиночные `NS_ERROR_PROXY_CONNECTION_REFUSED` на ~5.5 с (против ~10 с у успеха) прилетают то на одном узле, то на другом и каждый раз по разной площадке: 11×cian в 17:55, 10×yandex и 11×cian в 19:50, при том что 11×cian в 19:14 боевой крест прошёл зелено. На стабильное свойство пары не похоже; мои кресты идут залпом через один инстанс camoufox параллельно с боевым сбором, так что это может быть и лимит провайдера на одновременные сессии — утверждать не берусь, замера, который бы это развёл, я не делал. ### Осталось (дата и критерий записаны ДО факта) `domclick_city_sweep` — **10.08 04:43:59Z** (`scrape_schedules.next_run_at`). Проверяемое утверждение ровно одно: **первый бакет не тратится на узел, который до площадки не доходит** — в логах не должно быть `leased proxy id=1 provider=domclick` при активном бане пары. Что Домклик от этого соберётся — не обещаю, у него могут быть беды помимо узла.

Light1YT referenced this issue from a commit

2026-08-09 20:07:31 +00:00

fix(tradein/proxy): упавшая проба присваивала себе бан боевого сбора (#2800)

bot-backend referenced this issue

2026-08-09 20:08:23 +00:00

fix(tradein/proxy): упавшая проба присваивала себе бан боевого сбора (#2800) #2805

bot-backend referenced this issue from a commit

2026-08-09 20:13:12 +00:00

fix(tradein/proxy): упавшая проба присваивала себе бан боевого сбора (#2800) (#2805)

bot-backend referenced this issue

2026-08-10 08:04:52 +00:00

bot-backend referenced this issue

2026-08-12 12:42:50 +00:00

bot-backend referenced this issue

2026-08-13 05:29:58 +00:00

Домклик: блок бьёт внутри первой корзины, ротация узла его не видит — шесть корзин не доводятся никогда #2854

bot-backend referenced this issue

2026-08-13 05:34:16 +00:00

Проба узла спрашивает robots.txt, а работа — защищённый API: «пара здорова» ровно там, где свип получает QRATOR #2855

Light1YT referenced this issue from a commit

2026-08-13 07:28:30 +00:00

docs(tradein): снять устаревшее обоснование обрыва прогона Домклика

bot-backend referenced this issue

2026-08-13 07:28:32 +00:00

docs(tradein): снять устаревшее обоснование обрыва прогона Домклика (#2854) #2859

lekss361 added the

labels 2026-08-16 10:25:20 +00:00

lekss361 referenced this issue

2026-08-16 10:36:32 +00:00

feat(tradein): #3 — источник ДомКлик #400

lekss361 commented

2026-08-16 10:36:39 +00:00

Owner

Закрываю по итогам разбора трекера 16.08.2026

Вердикт: сделано кодом.

Три смерженных PR: узел для Домклика доходит до Домклика, проба спрашивает каждую площадку и пишет вердикт на пару «узел × источник», упавшая проба больше не присваивает себе бан боевого сбора.

Доказательство: 7cd8c63b (#2802), 08bb9d65 (#2803), 27e199e3 (#2805) — все с ссылкой на #2800

Независимая проверка. Вердикт отдельно проверялся вторым проходом, задачей которого было именно опровергнуть закрытие, а не подтвердить его:

Проверил все три части живьём. A (7cd8c63b, миграция 253): на проде SELECT из scrape_proxies — у ВСЕХ четырёх узлов provider_affinity='any', узел id=1 больше не зарезервирован за Домкликом. B (08bb9d65): в proxy_pool.py есть PROBE_SOURCES-крест (_probe_sources_for/_run_pair_probes), mark_source_probe пишет вердикт пары в существующую scrape_proxy_source_bans с reason='probe:browser' и снимает только СВОИ строки (only_reason в clear_source_bans); узловой вердикт (browser_fail_streak) считается по итогу всего креста, схлопывания диагнозов нет. Живые данные прода подтверждают исполнение: scrape_runs source='proxy_healthcheck' — 26 прогонов с pair_banned>0, последний 16.08 08:44 (pair_checked=4, pair_banned=1), в scrape_proxy_source_bans висит строка (1,'cian',reason='probe:browser') — то есть проба ловит именно то, чего старая не видела (Циан отдаёт заглушку с кодом 200). C (27e199e3) закрывает дефект, который автор сам нашёл и записал в комментарии: mark_banned теперь имеет WHERE у DO UPDATE (истёкшая ИЛИ своя ИЛИ боевой сбор), т.е. упавшая проба больше не присваивает себе чужой бан. Пункт 3 задачи (не превращать диагностику в нагрузку) соблюдён: такт 360 мин, browser_checked=1 за прогон. Остаточное (названо самим автором, не блокер закрытия): мигающая пара при такте 360 мин может врать в обе стороны, и fallback-заход acquire может отдать узел источнику без вердикта.

Если что-то из перечисленного всё же живо — переоткройте задачу, разбор мог упустить частный случай.

## Закрываю по итогам разбора трекера 16.08.2026 **Вердикт:** сделано кодом. Три смерженных PR: узел для Домклика доходит до Домклика, проба спрашивает каждую площадку и пишет вердикт на пару «узел × источник», упавшая проба больше не присваивает себе бан боевого сбора. **Доказательство:** 7cd8c63b (#2802), 08bb9d65 (#2803), 27e199e3 (#2805) — все с ссылкой на #2800 **Независимая проверка.** Вердикт отдельно проверялся вторым проходом, задачей которого было именно опровергнуть закрытие, а не подтвердить его: > Проверил все три части живьём. A (7cd8c63b, миграция 253): на проде SELECT из scrape_proxies — у ВСЕХ четырёх узлов provider_affinity='any', узел id=1 больше не зарезервирован за Домкликом. B (08bb9d65): в proxy_pool.py есть PROBE_SOURCES-крест (_probe_sources_for/_run_pair_probes), mark_source_probe пишет вердикт пары в существующую scrape_proxy_source_bans с reason='probe:browser' и снимает только СВОИ строки (only_reason в clear_source_bans); узловой вердикт (browser_fail_streak) считается по итогу всего креста, схлопывания диагнозов нет. Живые данные прода подтверждают исполнение: scrape_runs source='proxy_healthcheck' — 26 прогонов с pair_banned>0, последний 16.08 08:44 (pair_checked=4, pair_banned=1), в scrape_proxy_source_bans висит строка (1,'cian',reason='probe:browser') — то есть проба ловит именно то, чего старая не видела (Циан отдаёт заглушку с кодом 200). C (27e199e3) закрывает дефект, который автор сам нашёл и записал в комментарии: mark_banned теперь имеет WHERE у DO UPDATE (истёкшая ИЛИ своя ИЛИ боевой сбор), т.е. упавшая проба больше не присваивает себе чужой бан. Пункт 3 задачи (не превращать диагностику в нагрузку) соблюдён: такт 360 мин, browser_checked=1 за прогон. Остаточное (названо самим автором, не блокер закрытия): мигающая пара при такте 360 мин может врать в обе стороны, и fallback-заход acquire может отдать узел источнику без вердикта. Если что-то из перечисленного всё же живо — переоткройте задачу, разбор мог упустить частный случай.

lekss361 closed this issue

2026-08-16 10:36:39 +00:00

bot-backend referenced this issue

2026-08-27 21:44:27 +00:00

Домклик не собирается с 5 августа: 17 банов подряд, QRATOR рубит на первой из шести корзин #3118

bot-backend referenced this issue from a commit

2026-08-29 12:28:57 +00:00

fix(tradein/domclick): backfill ходил в сайдкар мимо прокси-пула (#3197 ч.1)

lekss361 referenced this issue

2026-08-29 12:29:25 +00:00

fix(tradein/domclick): detail-бэкфилл ходил в сайдкар мимо прокси-пула (#3197 ч.1) #3222

bot-backend referenced this issue from a commit