[ВЛАДЕЛЬЦУ] Сводка: 8 пунктов, которые не чинятся кодом — учётки, ключи, получатель уведомлений, два решения #2704

Open
opened 2026-08-06 06:23:36 +00:00 by bot-backend · 20 comments
Collaborator

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

Пересобрано 2026-08-07 07:35 MSK после ночи проверок. Пункт про PR #2680 снят — вы его смержили.


СРОЧНОЕ (есть срок)

1. Сегодня в 07:15 MSK удалятся 93 дома

Расписание house_dedup_merge живо: enabled=true, dry_run=false, такт неделя, следующий запуск 2026-08-08 04:15 UTC. Миграция, заводившая его, сеяла расписание выключенным и с пометкой «разрушительное». Кто-то включил, и с 27 июня оно молча отработало шесть раз: 119 домов удалено, 476 объявлений переехало.

Вчера добавлен журнал слияний со снимком удаляемой записи и проверенным откатом (#2740) — будущие слияния обратимы поимённо. Те 119 не вернуть.

Решить: (а) пусть идёт — теперь обратимо; (б) выключить до разбора; (в) на один такт перевести в сухой прогон и посмотреть 93 пары глазами. Мой голос за (в): обратимость снимает катастрофу, но не отвечает, правильны ли слияния, а правило выбора победителя в #2690 названо дефектным — сортировка ставит дом без объявлений первым.


УЧЁТКИ И КЛЮЧИ (действие в чужом интерфейсе)

2. Получатель уведомлений в GlitchTip — #2673

Самое дешёвое и самое недооценённое. События приходят: по проекту trade-in накоплено 2 861 группа ошибок, за сутки 77 живых групп. Правил оповещения 0, получателей 0, отправлено 0 за всю историю.

Это не «мониторинг не настроен», а исправная диагностика, пишущая в ящик, который ни разу не открывали. За сутки мы починили шесть сторожей — все шесть срабатывают в пустоту, пока адресата нет.

Оговорка: первое правило не делать «слать всё» — 10 571 TimeoutError утопит остальное.

3. DaData: включить услугу «Стандартизация» — #2704

Стандартизация адресов сломана 69 дней, в двух формах подряд:

30.05 → 12.07   389 событий   HTTP 403 — auth/secret rejected. Проверь токен.
12.07 → 07.08   123 события   HTTP 403 — услуга CLEAN ВЫКЛЮЧЕНА на аккаунте
                              (токен валиден, НЕ отклонён)

Смена формулировки 12 июля значит, что токен тогда обновили и остановились на полпути. Ошибка сама говорит, что делать. Токен менять не надо.

4. Учётная запись Циана — #2700

Куки протухли 30 июня, автоперелогин недоступен (логин задекларирован в конфиге, в проде отсутствует).

Цена: detail-страницы отдают 403 на 50 из 50 попыток; все домовые поля Циана нулевые во всех 9 457 домах (серия при этом выводится на экран); cian_valuation, седьмой источник эстиматора, не написал ни строки с 29 июня — то есть молча отсутствует в каждой выданной оценке.

5. Куки Домклика — истекли 3 августа

Загрузка ручная (POST /scrape/domclick/upload-cookies), авто-логина нет.

Поправка после ночи: у нулевого сбора Домклика как минимум три разные причины — антибот (внешнее), протухшие куки (вы), отказ нашего сайдкара (наше). Сегодня в 03:34 обход упал именно на третьей: двойной 500 от tradein-browser, площадка не участвовала. Куки нужны, но не всё сводится к ним.

6. Действующий ключ Яндекс-геокодера — #2585 — СНЯТ 10.08, от вас ничего не нужно

Проверено живым запросом из контейнера 10.08: ключ отвечает HTTP 200, точный геокод, переменная в .env.runtime не менялась с 04.07 — 403 пропал сам. И даже это неважно: по вашему решению от 31.07 Яндекс-геокодер вырезан из кода (#2593, −845 строк), в прод-контейнере ноль ссылок на него. Цена простоя = 0. #2585 закрыт.

Настоящая цена по геокодированию лежит в другом месте и кодом чинится: 3 270 активных объявлений без координат (34.9% активного Авито), из них 2 446 — внутри свежего пула аналогов, то есть 12.7% аналогов невидимы радиусному поиску. У 1 123 из них в адрес подклеен рейтинг Авито («ул. Ткачей,17·5,0 · 4 отзыва») — доля без координат у таких 100%. Заведено отдельно.

7. Токен ASOCKS для ротации прокси — #2638

Ротация написана и не может включиться. Прошлой ночью два узла из четырёх выключились сами, для трёх источников остался один.

Честная оценка ущерба скромнее, чем я писал вчера: одного узла на текущую ночную нагрузку хватило — собрано 447 лотов Авито, 1 008 Циана, 492 обогащения Яндекса, всё при нуле ошибок. Теснота опасна отсутствием резерва, а не тем, что сбор стоит: следующий отказ оставляет ноль.


РЕШЕНИЯ (не действие, а выбор)

8. PR #2661 — цены станут ниже на 2.25%

Фильтр свежести в якоре дома и знаменателе коэффициента выкупа. Замер на 1 040 реальных оценок: −2.25% к предлагаемым ценам. Это не баг-фикс с очевидным знаком — предложения станут ниже, и это ваше решение.

9. DOM.РФ: как проверять снятие бана — #2443

WAF-блокировка IP нашего сервера с 24 мая. Живые запросы туда запрещены жёстко, поэтому проверить снятие автоматикой нельзя — попытка проверки и есть запрещённое действие. Решить: другой адрес, обращение к площадке, или признать источник закрытым.


ЧТО НЕ ЖДЁТ ВАС

#2687 (нужны ли два недельных полных обхода Авито) ждёт данных, а не решения — и данных пока нет: ни один полный обход не завершался с 3 июля, следующий 10.08. Решать по одной точке нельзя; предлагаю не раньше чем через два-три прогона.

Всё, что **не может быть сделано без вас**. Собрано в одном месте, потому что по каждой задаче отдельно неочевидно, что она ждёт именно вас. Пересобрано 2026-08-07 07:35 MSK после ночи проверок. Пункт про PR #2680 снят — вы его смержили. --- # СРОЧНОЕ (есть срок) ## 1. Сегодня в 07:15 MSK удалятся 93 дома Расписание `house_dedup_merge` живо: `enabled=true`, `dry_run=false`, такт неделя, следующий запуск **2026-08-08 04:15 UTC**. Миграция, заводившая его, сеяла расписание **выключенным** и с пометкой «разрушительное». Кто-то включил, и с 27 июня оно молча отработало шесть раз: **119 домов удалено, 476 объявлений переехало**. Вчера добавлен журнал слияний со снимком удаляемой записи и проверенным откатом (#2740) — будущие слияния обратимы поимённо. Те 119 не вернуть. **Решить:** (а) пусть идёт — теперь обратимо; (б) выключить до разбора; (в) **на один такт перевести в сухой прогон** и посмотреть 93 пары глазами. Мой голос за (в): обратимость снимает катастрофу, но не отвечает, правильны ли слияния, а правило выбора победителя в #2690 названо дефектным — сортировка ставит дом **без** объявлений первым. --- # УЧЁТКИ И КЛЮЧИ (действие в чужом интерфейсе) ## 2. Получатель уведомлений в GlitchTip — #2673 **Самое дешёвое и самое недооценённое.** События приходят: по проекту trade-in накоплено **2 861 группа ошибок**, за сутки 77 живых групп. Правил оповещения `0`, получателей `0`, отправлено `0` за всю историю. Это не «мониторинг не настроен», а исправная диагностика, пишущая в ящик, который ни разу не открывали. За сутки мы починили шесть сторожей — все шесть срабатывают в пустоту, пока адресата нет. Оговорка: первое правило не делать «слать всё» — 10 571 `TimeoutError` утопит остальное. ## 3. DaData: включить услугу «Стандартизация» — #2704 Стандартизация адресов сломана **69 дней**, в двух формах подряд: ``` 30.05 → 12.07 389 событий HTTP 403 — auth/secret rejected. Проверь токен. 12.07 → 07.08 123 события HTTP 403 — услуга CLEAN ВЫКЛЮЧЕНА на аккаунте (токен валиден, НЕ отклонён) ``` Смена формулировки 12 июля значит, что токен тогда обновили и остановились на полпути. **Ошибка сама говорит, что делать.** Токен менять не надо. ## 4. Учётная запись Циана — #2700 Куки протухли **30 июня**, автоперелогин недоступен (логин задекларирован в конфиге, в проде отсутствует). Цена: detail-страницы отдают **403 на 50 из 50** попыток; все домовые поля Циана нулевые во **всех 9 457 домах** (серия при этом выводится на экран); `cian_valuation`, седьмой источник эстиматора, не написал ни строки с 29 июня — то есть молча отсутствует в каждой выданной оценке. ## 5. Куки Домклика — истекли 3 августа Загрузка ручная (`POST /scrape/domclick/upload-cookies`), авто-логина нет. **Поправка после ночи:** у нулевого сбора Домклика **как минимум три разные причины** — антибот (внешнее), протухшие куки (вы), отказ нашего сайдкара (наше). Сегодня в 03:34 обход упал именно на третьей: двойной 500 от `tradein-browser`, площадка не участвовала. Куки нужны, но не всё сводится к ним. ## ~~6. Действующий ключ Яндекс-геокодера — #2585~~ — СНЯТ 10.08, от вас ничего не нужно Проверено живым запросом из контейнера 10.08: **ключ отвечает HTTP 200**, точный геокод, переменная в `.env.runtime` не менялась с 04.07 — 403 пропал сам. И даже это неважно: по вашему решению от 31.07 Яндекс-геокодер **вырезан из кода** (#2593, −845 строк), в прод-контейнере ноль ссылок на него. Цена простоя = 0. #2585 закрыт. Настоящая цена по геокодированию лежит в другом месте и кодом чинится: **3 270 активных объявлений без координат** (34.9% активного Авито), из них 2 446 — внутри свежего пула аналогов, то есть **12.7% аналогов невидимы радиусному поиску**. У 1 123 из них в адрес подклеен рейтинг Авито («ул. Ткачей,17·5,0 · 4 отзыва») — **доля без координат у таких 100%**. Заведено отдельно. ## 7. Токен ASOCKS для ротации прокси — #2638 Ротация написана и не может включиться. Прошлой ночью два узла из четырёх выключились сами, для трёх источников остался один. **Честная оценка ущерба скромнее, чем я писал вчера:** одного узла на текущую ночную нагрузку хватило — собрано 447 лотов Авито, 1 008 Циана, 492 обогащения Яндекса, всё при нуле ошибок. Теснота опасна **отсутствием резерва**, а не тем, что сбор стоит: следующий отказ оставляет ноль. --- # РЕШЕНИЯ (не действие, а выбор) ## 8. PR #2661 — цены станут ниже на 2.25% Фильтр свежести в якоре дома и знаменателе коэффициента выкупа. Замер на 1 040 реальных оценок: **−2.25%** к предлагаемым ценам. Это не баг-фикс с очевидным знаком — предложения станут ниже, и это ваше решение. ## 9. DOM.РФ: как проверять снятие бана — #2443 WAF-блокировка IP нашего сервера с 24 мая. Живые запросы туда запрещены жёстко, поэтому проверить снятие автоматикой нельзя — попытка проверки и есть запрещённое действие. Решить: другой адрес, обращение к площадке, или признать источник закрытым. --- # ЧТО НЕ ЖДЁТ ВАС **#2687** (нужны ли два недельных полных обхода Авито) ждёт **данных**, а не решения — и данных пока нет: ни один полный обход не завершался с 3 июля, следующий 10.08. Решать по одной точке нельзя; предлагаю не раньше чем через два-три прогона.
Author
Collaborator

Уточнение к пункту 5 (ASOCKS) по итогам #2698 — нового пункта НЕ добавляется

Разбирал домовую оценку Авито (#2698, 34 дня нулевых прогонов). В шапке #2698 значится «403 — auth rejected / quota exceeded», что читается как «протухла учётка Авито». Это не так, и вашего действия по Авито не требуется:

  • в IMV-флоу авторизации нет вообще — providers/avito/imv.py шлёт анонимные XHR без куки и токенов;
  • «auth rejected / quota exceeded» — наш собственный текст в _raise_for_status_categorized для любого 401/403, а не сообщение площадки;
  • то есть 403 — это анти-бот отказ по исходящему IP, а не по учётным данным. Обновлять нечего.

Основную часть (все 1240 отказов с 503 и 83 с 500) чинит код — PR #2708: путь домовой оценки ходил в браузерный сайдкар без прокси из пула и уезжал через единственный env-узел, который для Авито не предназначен.

Остаток после этого PR упирается ровно в пункт 5 этого списка: один рабочий исходящий IP на все источники, ротации нет. Так что пункт 5 стоит читать шире, чем «37 из 53 банов» — он же держит и домовую оценку Авито.

Нужно от вас: по-прежнему только ASOCKS_API_TOKEN (пункт 5). Ничего дополнительного #2698 не добавляет.

Отдельно, для полноты картины по пункту 7 (PR #2680): пути app/services/house_imv_backfill.py и app/services/product_handlers.py в scraper-allowlist деплоя не входят — правка только в них доезжает до tradein-backend, но не до tradein-scraper, который эти задачи и исполняет. PR #2708 попадает в контейнер только потому, что задевает ещё и packages/scraper-kit/**. Это ровно тот класс, который закрывает #2680.

## Уточнение к пункту 5 (ASOCKS) по итогам #2698 — нового пункта НЕ добавляется Разбирал домовую оценку Авито (#2698, 34 дня нулевых прогонов). В шапке #2698 значится «403 — auth rejected / quota exceeded», что читается как «протухла учётка Авито». **Это не так, и вашего действия по Авито не требуется:** - в IMV-флоу авторизации нет вообще — `providers/avito/imv.py` шлёт анонимные XHR без куки и токенов; - «auth rejected / quota exceeded» — наш собственный текст в `_raise_for_status_categorized` для любого 401/403, а не сообщение площадки; - то есть 403 — это анти-бот отказ по **исходящему IP**, а не по учётным данным. Обновлять нечего. Основную часть (все 1240 отказов с 503 и 83 с 500) чинит код — PR #2708: путь домовой оценки ходил в браузерный сайдкар без прокси из пула и уезжал через единственный env-узел, который для Авито не предназначен. Остаток после этого PR упирается ровно в пункт 5 этого списка: один рабочий исходящий IP на все источники, ротации нет. Так что пункт 5 стоит читать шире, чем «37 из 53 банов» — он же держит и домовую оценку Авито. **Нужно от вас: по-прежнему только `ASOCKS_API_TOKEN` (пункт 5). Ничего дополнительного #2698 не добавляет.** Отдельно, для полноты картины по пункту 7 (PR #2680): пути `app/services/house_imv_backfill.py` и `app/services/product_handlers.py` в scraper-allowlist деплоя не входят — правка только в них доезжает до `tradein-backend`, но не до `tradein-scraper`, который эти задачи и исполняет. PR #2708 попадает в контейнер только потому, что задевает ещё и `packages/scraper-kit/**`. Это ровно тот класс, который закрывает #2680.
Author
Collaborator

Ещё два пункта по итогам разбора нулевого detail-обогащения Авито и Яндекса (PR #2738, #2739 — смержены и на проде).

9. Решение: обогащать ли новостройки Яндекса — 3 535 объявлений

У 3 535 из 15 511 необогащённых yandex-объявлений source_url ведёт не на Яндекс, а на сайт застройщика (macroserver.ru, prospect-federation.ru, strana.com, ten-stroy.ru, …) — так карточки новостроек уходят с выдачи. Наш парсер разбирает только realty.yandex.ru/offer/<id>/: он отвергает такой URL регуляркой, ещё не открыв страницу. Обогащено из них за всю историю — ноль.

С PR #2738 они больше не попадают в очередь (и не обрывают прогон, что и было причиной 32 «пустых» прогонов из 53). Их количество видно в counters.unenrichable_pending — это честная пометка, а не тихая пропажа.

Нужно решение: нужны ли по новостройкам Яндекса детальные поля вообще (сейчас по ним есть только данные выдачи — цена, комнаты, площадь).

Если нужны — есть один непроверенный путь: у 3 523 из 3 535 сохранён yandex_offer_id, то есть URL карточки Яндекса можно построить самим. Отдаёт ли Яндекс такую страницу для партнёрских новостроек, кодом не выяснить — нужна одна ручная проверка живым запросом (агентам живые запросы к площадкам запрещены). Если страница отдаётся, гейт очереди расширяется на построенный URL; если нет — пункт закрывается как «данные приходят другим путём».

10. Авито: detail-обогощение даёт ноль 25-й день — ответ будет завтра, дальше упирается в п.5

Последний прогон avito_detail_backfill с ненулевым обогащением — 12 июля. С тех пор ночи выглядят так: либо 5 попыток и 5 блоков, либо ~1600 попыток и ~1600 отказов (3-5 августа, с выеданием всего бюджета 9000 с), либо пустая очередь. При этом браузерный тракт (detail-фаза avito_city_sweep) обогащает 6-23 объявления в сутки — то есть Авито закрыт именно для curl-тракта, которым ходит backfill.

Кто именно отказывает — площадка или наш прокси-тракт — из имеющихся данных не устанавливается: поштучные отказы логируются WARNING, в GlitchTip уезжает только ERROR, а логи контейнера пропадают при его пересоздании (сегодня прогоны 11:05 и 12:40 остались без логов после деплоя в 12:57). PR #2739 это закрывает: с завтрашнего прогона (12:39 UTC) самая частая причина отказа с её долей пишется прямо в статус прогона и переживает перезапуск.

Действий пока не нужно. Но если завтрашняя причина окажется прокси-отказом (CONNECT tunnel failed и подобное), это ровно ваш пункт 5 — токен ASOCKS: сегодня оба detail-backfill'а (Авито и Яндекс) ходят через один и тот же резидентный узел, он же обслуживает Домклик.

Ещё два пункта по итогам разбора нулевого detail-обогащения Авито и Яндекса (PR #2738, #2739 — смержены и на проде). ## 9. Решение: обогащать ли новостройки Яндекса — 3 535 объявлений У 3 535 из 15 511 необогащённых yandex-объявлений `source_url` ведёт **не на Яндекс**, а на сайт застройщика (macroserver.ru, prospect-federation.ru, strana.com, ten-stroy.ru, …) — так карточки новостроек уходят с выдачи. Наш парсер разбирает только `realty.yandex.ru/offer/<id>/`: он отвергает такой URL регуляркой, ещё не открыв страницу. Обогащено из них за всю историю — **ноль**. С PR #2738 они больше не попадают в очередь (и не обрывают прогон, что и было причиной 32 «пустых» прогонов из 53). Их количество видно в `counters.unenrichable_pending` — это честная пометка, а не тихая пропажа. **Нужно решение:** нужны ли по новостройкам Яндекса детальные поля вообще (сейчас по ним есть только данные выдачи — цена, комнаты, площадь). Если нужны — есть один непроверенный путь: у 3 523 из 3 535 сохранён `yandex_offer_id`, то есть URL карточки Яндекса можно построить самим. Отдаёт ли Яндекс такую страницу для партнёрских новостроек, кодом не выяснить — нужна одна ручная проверка живым запросом (агентам живые запросы к площадкам запрещены). Если страница отдаётся, гейт очереди расширяется на построенный URL; если нет — пункт закрывается как «данные приходят другим путём». ## 10. Авито: detail-обогощение даёт ноль 25-й день — ответ будет завтра, дальше упирается в п.5 Последний прогон `avito_detail_backfill` с ненулевым обогащением — **12 июля**. С тех пор ночи выглядят так: либо 5 попыток и 5 блоков, либо ~1600 попыток и ~1600 отказов (3-5 августа, с выеданием всего бюджета 9000 с), либо пустая очередь. При этом браузерный тракт (detail-фаза `avito_city_sweep`) обогащает 6-23 объявления в сутки — то есть Авито закрыт именно для curl-тракта, которым ходит backfill. Кто именно отказывает — площадка или наш прокси-тракт — из имеющихся данных не устанавливается: поштучные отказы логируются WARNING, в GlitchTip уезжает только ERROR, а логи контейнера пропадают при его пересоздании (сегодня прогоны 11:05 и 12:40 остались без логов после деплоя в 12:57). PR #2739 это закрывает: с завтрашнего прогона (12:39 UTC) самая частая причина отказа с её долей пишется прямо в статус прогона и переживает перезапуск. **Действий пока не нужно.** Но если завтрашняя причина окажется прокси-отказом (`CONNECT tunnel failed` и подобное), это ровно ваш пункт 5 — токен ASOCKS: сегодня оба detail-backfill'а (Авито и Яндекс) ходят через **один и тот же** резидентный узел, он же обслуживает Домклик.
Author
Collaborator

Поправка к пункту 1: не 93 дома, а 6

Я дал вам число 93 как срок с сегодняшней датой. Оно неверно. Пересчитал тем же выражением, которое исполняет сама задача (_mapping_sql, оба прохода, с гео-ограждением 250 м и защитой от разных ФИАС), в 08:40 UTC:

проход будет удалено кластеров
ФИАС 0 0
канон-адрес 6 6

Всего домов в базе 9625.

Почему разрыв так велик

В кластерах-дублях по канон-адресу лежит 1606 проигравших. До удаления доходят 6, остальных снимают ограждения:

отсеяно сколько
нет координат у победителя или проигравшего 1024
дальше 250 м друг от друга 576
разный ФИАС при обоих непустых 8

То есть ограждения работают и снимают 99.6% кандидатов. Число 93 не воспроизводится ни одним из промежуточных срезов — ни «все проигравшие», ни «домов в кластерах» (2937), ни историческая сумма удалённого (119). Откуда я его взял, восстановить не могу; считайте его моей ошибкой, а не изменившимся состоянием.

Что это меняет в решении

Срочность была преувеличена мной. По существу вариант (в) — один такт в сухом прогоне — становится дешевле, а не дороже: шесть пар просматриваются глазами за минуты, а не девяносто три. Голос за (в) оставляю по прежней причине: обратимость (#2740) снимает катастрофу, но не отвечает, правильны ли слияния, а правило выбора победителя названо дефектным в #2690.

Если решения не будет, завтра в 04:15 UTC удалятся эти 6 записей, поимённо обратимо через журнал #2740.

Побочная находка, которая важнее пункта 1

1024 проигравших не схлопываются потому, что у одной из сторон нет координат. Это, судя по всему, и есть настоящее содержание #2690 («781 дубль домов не схлопнуть»): дубли не «не находятся», они находятся и отбраковываются гео-ограждением из-за пустого geom. Ограждение при этом ведёт себя правильно — без координат проверить, что это один дом, нечем. Значит, задача не в ослаблении ограждения, а в геокодировании этих домов. Внесу отдельным замером в #2690, здесь от вас ничего не требуется.

## Поправка к пункту 1: не 93 дома, а 6 Я дал вам число 93 как срок с сегодняшней датой. Оно неверно. Пересчитал **тем же выражением, которое исполняет сама задача** (`_mapping_sql`, оба прохода, с гео-ограждением 250 м и защитой от разных ФИАС), в 08:40 UTC: | проход | будет удалено | кластеров | |---|---|---| | ФИАС | **0** | 0 | | канон-адрес | **6** | 6 | Всего домов в базе 9625. ### Почему разрыв так велик В кластерах-дублях по канон-адресу лежит **1606** проигравших. До удаления доходят 6, остальных снимают ограждения: | отсеяно | сколько | |---|---| | нет координат у победителя или проигравшего | 1024 | | дальше 250 м друг от друга | 576 | | разный ФИАС при обоих непустых | 8 | То есть ограждения работают и снимают 99.6% кандидатов. Число 93 не воспроизводится ни одним из промежуточных срезов — ни «все проигравшие», ни «домов в кластерах» (2937), ни историческая сумма удалённого (119). Откуда я его взял, восстановить не могу; считайте его моей ошибкой, а не изменившимся состоянием. ### Что это меняет в решении Срочность была преувеличена мной. По существу вариант (в) — один такт в сухом прогоне — становится **дешевле**, а не дороже: шесть пар просматриваются глазами за минуты, а не девяносто три. Голос за (в) оставляю по прежней причине: обратимость (#2740) снимает катастрофу, но не отвечает, правильны ли слияния, а правило выбора победителя названо дефектным в #2690. Если решения не будет, завтра в 04:15 UTC удалятся эти 6 записей, поимённо обратимо через журнал #2740. ### Побочная находка, которая важнее пункта 1 **1024 проигравших не схлопываются потому, что у одной из сторон нет координат.** Это, судя по всему, и есть настоящее содержание #2690 («781 дубль домов не схлопнуть»): дубли не «не находятся», они находятся и отбраковываются гео-ограждением из-за пустого `geom`. Ограждение при этом ведёт себя правильно — без координат проверить, что это один дом, нечем. Значит, задача не в ослаблении ограждения, а в геокодировании этих домов. Внесу отдельным замером в #2690, здесь от вас ничего не требуется.
Author
Collaborator

Поправка к моему предыдущему комментарию, к последнему абзацу.

Я написал, что 1024 дубля, отбракованных из-за отсутствия координат, — «настоящее содержание #2690». Это неверно, и я не прочитал #2690 целиком, прежде чем так сказать. Там измерено другое: 764 из 781 пары блокируются расстоянием, то есть ограждение отвергает их по существу — дома правда далеко друг от друга. Плюс отдельный дефект: предложенный там ключ выводится из того же адреса, что и защита, и потому её отменяет.

Моё наблюдение самостоятельное и вынесено в #2771: 20.2% домов без координат, потому что геокодер чинит объявление, а в дом координаты не возвращаются. От вас там ничего не требуется. Числа на #2704 и решение по пункту 1 (шесть домов, не 93) поправка не меняет.

Поправка к моему предыдущему комментарию, к последнему абзацу. Я написал, что 1024 дубля, отбракованных из-за отсутствия координат, — «настоящее содержание #2690». Это неверно, и я не прочитал #2690 целиком, прежде чем так сказать. Там измерено другое: 764 из 781 пары блокируются **расстоянием**, то есть ограждение отвергает их по существу — дома правда далеко друг от друга. Плюс отдельный дефект: предложенный там ключ выводится из того же адреса, что и защита, и потому её отменяет. Моё наблюдение самостоятельное и вынесено в **#2771**: 20.2% домов без координат, потому что геокодер чинит объявление, а в дом координаты не возвращаются. От вас там ничего не требуется. Числа на #2704 и решение по пункту 1 (шесть домов, не 93) поправка не меняет.
Author
Collaborator

Сверка всех пунктов 2026-08-07 ~12:00 MSK: сам собой не отпал ни один, один стал хуже, по одному пришёл обещанный ответ

Задачу не закрываю. Проверял, не отпали ли пункты сами. Ответ: нет, ни один. Ниже — только
то, что изменилось или уточнилось со вчера.

п.1 — расписание живо, журнал на проде, решение всё ещё за вами

house_dedup_merge | enabled=true | dry_run=false | такт 7 дней | next 2026-08-08 04:15 UTC
house_merge_log   | таблица есть (16 колонок, снимок удаляемой строки) | записей 0
house_merge_undo  | функция на проде

Журнал доехал и проверен по схеме, но на настоящем прогоне ещё не работал — записей ноль.
Завтрашний прогон будет для него первым. Ключ схлопывания, правило выбора победителя и
гео-страж (#2690 п.2/п.3) не тронуты — то есть завтра проход пойдёт с тем же дефектным правилом
выбора победителя, только обратимо.

п.2 — GlitchTip: за сутки ничего не изменилось

правил 0 · получателей 0 · отправлено 0
групп: backend 3 707 (было 3 661) · trade-in 2 882 (было 2 861)
за сутки: backend 81 группа / 886 событий · trade-in 21 / 331

За сутки в эпике починены ещё два сторожа (#2670, #2703). Оба будут срабатывать в пустоту.

п.3 — DaData: не отпал, счётчик растёт

141 события (было 123)   «услуга CLEAN (Стандартизация) выключена на аккаунте»
последнее — 2026-08-07 08:15

26-й день. Токен по-прежнему менять не надо.

п.4 — Циан: не отпал

Куки протухли 37 дней назад (прогон 07.08 02:03 честно сказал это словами). detail — 50 из 50
403
сегодня ночью, статус прогона всё равно done. Домовые поля 0 из 9 625.
cian_valuation — 139 строк, последняя 29.06; контрольная группа yandex_valuation — 1 531
строка, последняя сегодня 08:10. То есть оценки запрашиваются, а седьмой источник в них
по-прежнему молча отсутствует.

Побочно: правка «просмотры Циана» (#2669) доехала до контейнера и проверена вызовом, но даёт
ноль по той же причине — detail не доходит. Ещё одна работа, лежащая за этими куками.

п.5 — Домклик: не отпал

последнее объявление Домклика в базе:  2026-08-05 05:43
07.08 03:34  domclick_city_sweep       failed  «fetch errors — 0 listings», 0 из 6 бакетов
06.08 15:17  domclick_detail_backfill  banned   3 блока, 0 обогащений из 3

Ваша вчерашняя поправка («три разные причины») подтверждается: за двое суток отметились и
блоки, и наши собственные отказы.

п.6 — ключ Яндекс-геокодера: моей пробой не проверен

В GlitchTip группы «Invalid api key» нет — но это ничего не доказывает, потому что канал
никому не пишет и не всякий отказ туда попадает. Записываю как «не проверено», а не «отпало».

п.7 — ASOCKS: стало хуже, чем вчера

id  метка                  affinity   включён
1   asocks-residential-1   domclick   да
9   asocks-mobile-1        any        да
10  asocks-mobile-2        any        да
11  asocks-mobile-3        any        НЕТ  ← выключен

Вчера вы читали «три узла общего назначения». Сегодня их два, третий выключился. Резерва,
про отсутствие которого вы писали, стало ещё меньше.

п.8 — PR #2661 по-прежнему открыт, решение не принято

п.10 — обещанный ответ по Авито пришёл, и он НЕ сводится к пункту 7 напрямую

PR #2739 сработал: причина отказа теперь в статусе прогона и пережила перезапуск.

3368 | avito_detail_backfill | 2026-08-07 07:55 | banned | ban_kind=platform
     остановлен блоками источника — blocked=5, обогащено 0 из 5 попыток;
     причина: AvitoBlockedError: Avito detail HTTP 403 for <url> (5 из 5)

Вчерашнее условие было: «если причина окажется прокси-отказом (CONNECT tunnel failed и
подобное) — это ваш пункт 7». Причина другая: площадка отдаёт 403 на все 5 попыток,
транспортного отказа прокси нет.

Осторожная трактовка: 403 в этом флоу — отказ по нашему исходящему IP (авторизации в нём
нет, это установлено в #2698), поэтому ротация адресов ему помогла бы. Но это уже не «прокси
не работает», а «адрес сожжён», и утверждать, что новый токен это чинит, я на одной точке не
могу. Правильнее сказать: пункт 7 остаётся единственным доступным рычагом, но прямого
доказательства, что он снимет именно этот 403, нет.

Ничего не отпало

Все девять исходных пунктов и оба добавленных остаются вашими.

## Сверка всех пунктов 2026-08-07 ~12:00 MSK: сам собой не отпал ни один, один стал хуже, по одному пришёл обещанный ответ Задачу не закрываю. Проверял, не отпали ли пункты сами. Ответ: **нет, ни один**. Ниже — только то, что изменилось или уточнилось со вчера. ### п.1 — расписание живо, журнал на проде, решение всё ещё за вами ``` house_dedup_merge | enabled=true | dry_run=false | такт 7 дней | next 2026-08-08 04:15 UTC house_merge_log | таблица есть (16 колонок, снимок удаляемой строки) | записей 0 house_merge_undo | функция на проде ``` Журнал доехал и проверен по схеме, но **на настоящем прогоне ещё не работал** — записей ноль. Завтрашний прогон будет для него первым. Ключ схлопывания, правило выбора победителя и гео-страж (#2690 п.2/п.3) не тронуты — то есть завтра проход пойдёт с тем же дефектным правилом выбора победителя, только обратимо. ### п.2 — GlitchTip: за сутки ничего не изменилось ``` правил 0 · получателей 0 · отправлено 0 групп: backend 3 707 (было 3 661) · trade-in 2 882 (было 2 861) за сутки: backend 81 группа / 886 событий · trade-in 21 / 331 ``` За сутки в эпике починены ещё два сторожа (#2670, #2703). Оба будут срабатывать в пустоту. ### п.3 — DaData: не отпал, счётчик растёт ``` 141 события (было 123) «услуга CLEAN (Стандартизация) выключена на аккаунте» последнее — 2026-08-07 08:15 ``` 26-й день. Токен по-прежнему менять не надо. ### п.4 — Циан: не отпал Куки протухли 37 дней назад (прогон 07.08 02:03 честно сказал это словами). detail — **50 из 50 403** сегодня ночью, статус прогона всё равно `done`. Домовые поля 0 из 9 625. `cian_valuation` — 139 строк, последняя 29.06; контрольная группа `yandex_valuation` — 1 531 строка, последняя **сегодня 08:10**. То есть оценки запрашиваются, а седьмой источник в них по-прежнему молча отсутствует. Побочно: правка «просмотры Циана» (#2669) доехала до контейнера и проверена вызовом, но даёт ноль по той же причине — detail не доходит. Ещё одна работа, лежащая за этими куками. ### п.5 — Домклик: не отпал ``` последнее объявление Домклика в базе: 2026-08-05 05:43 07.08 03:34 domclick_city_sweep failed «fetch errors — 0 listings», 0 из 6 бакетов 06.08 15:17 domclick_detail_backfill banned 3 блока, 0 обогащений из 3 ``` Ваша вчерашняя поправка («три разные причины») подтверждается: за двое суток отметились и блоки, и наши собственные отказы. ### п.6 — ключ Яндекс-геокодера: **моей пробой не проверен** В GlitchTip группы «Invalid api key» нет — но это ничего не доказывает, потому что канал никому не пишет и не всякий отказ туда попадает. Записываю как «не проверено», а не «отпало». ### п.7 — ASOCKS: **стало хуже, чем вчера** ``` id метка affinity включён 1 asocks-residential-1 domclick да 9 asocks-mobile-1 any да 10 asocks-mobile-2 any да 11 asocks-mobile-3 any НЕТ ← выключен ``` Вчера вы читали «три узла общего назначения». Сегодня их **два**, третий выключился. Резерва, про отсутствие которого вы писали, стало ещё меньше. ### п.8 — PR #2661 по-прежнему открыт, решение не принято ### п.10 — обещанный ответ по Авито пришёл, и он НЕ сводится к пункту 7 напрямую PR #2739 сработал: причина отказа теперь в статусе прогона и пережила перезапуск. ``` 3368 | avito_detail_backfill | 2026-08-07 07:55 | banned | ban_kind=platform остановлен блоками источника — blocked=5, обогащено 0 из 5 попыток; причина: AvitoBlockedError: Avito detail HTTP 403 for <url> (5 из 5) ``` Вчерашнее условие было: «если причина окажется прокси-отказом (`CONNECT tunnel failed` и подобное) — это ваш пункт 7». **Причина другая: площадка отдаёт 403 на все 5 попыток**, транспортного отказа прокси нет. Осторожная трактовка: 403 в этом флоу — отказ по нашему **исходящему IP** (авторизации в нём нет, это установлено в #2698), поэтому ротация адресов ему помогла бы. Но это уже не «прокси не работает», а «адрес сожжён», и утверждать, что новый токен это чинит, я на одной точке не могу. Правильнее сказать: **пункт 7 остаётся единственным доступным рычагом, но прямого доказательства, что он снимет именно этот 403, нет.** ### Ничего не отпало Все девять исходных пунктов и оба добавленных остаются вашими.
Author
Collaborator

Два новых пункта, которые тоже ждут вас

Разбор всех открытых задач добавил к списку ещё два. Оба — решения, а не работа.

9. Публиковать ли 5432 на боевом хосте — #2757, пункт 3

Вопрос задан 06.08 в 21:27 и остался без ответа. Первые два пункта закрыты: гейт написан и проверен на слом — вписали ports: - 5432:5432 в настоящий ci-tradein.yml, сборка покраснела с указанием файла, строки и порта; на безопасной форме молчит.

Живая проверка сегодня в момент, когда CI действительно бежал: три сервис-контейнера Postgres, все в bridge, портов не публикуют; боевой tradein-postgres наружу тоже ничего не выставляет.

Остаётся ваше: должен ли 5432 вообще быть публикуемым на этом хосте, хоть когда-нибудь. Если нет — гейт можно ужесточить до полного запрета. Если да (например для ручного доступа) — надо назвать условие, при котором это допустимо, иначе гейт рано или поздно отключат ради разовой задачи.

10. Потолок системного журнала — правка в конфигурации хоста

/etc/systemd/journald.conf пуст: секция есть, все параметры закомментированы, drop-in нет. Журнал сейчас 2.4 ГБ.

Значение имеет не размер, а умолчание SystemKeepFree — оно держит 15% файловой системы свободными и при их исчерпании перестаёт писать. Для 145 ГБ порог около 21.75 ГБ свободного; сейчас свободно 28 ГБ, то есть запас 6 ГБ, а не 28.

Отсюда неприятное свойство: вчерашняя правка «логи переживают пересоздание контейнера» имеет необъявленную зависимость от свободного места. Когда диск подойдёт к порогу, отказ будет выглядеть как «логов за вчера почему-то нет» — ровно тот симптом, ради устранения которого правка делалась, и в форме, которую трудно связать с причиной.

Правка на одну строку (SystemMaxUse= + SystemKeepFree=), после неё отказ становится предсказуемым: старые записи ротируются, а не отключается запись. Но это системная конфигурация хоста, а не наш код — скажите слово, и сделаю.

Оговорка, чтобы не читалось тревожнее, чем есть: диск не убегает. Резервные копии (11 ГБ) ротируются корректно, ровно недельное окно; дамп основной БД вырос на 27 МБ за шесть суток. При 28 ГБ свободного и таком темпе запас — порядка двух лет. Разбор в #2761.


Поправка к формулировке пункта 7

По разбору он стал хуже: узел asocks-mobile-3 выключился, узлов общего назначения теперь два, а не три.

И отдельно про пункт 10 из прежней нумерации — обещанная причина пришла и оказалась не той: AvitoBlockedError: HTTP 403 (5 из 5), ban_kind=platform. Это отказ площадки, а не транспортный отказ прокси. К токену ASOCKS сводится только косвенно, через репутацию адресов; прямого доказательства нет, и я не буду делать вид, что оно есть.

## Два новых пункта, которые тоже ждут вас Разбор всех открытых задач добавил к списку ещё два. Оба — решения, а не работа. ### 9. Публиковать ли 5432 на боевом хосте — #2757, пункт 3 Вопрос задан 06.08 в 21:27 и остался без ответа. Первые два пункта закрыты: гейт написан и **проверен на слом** — вписали `ports: - 5432:5432` в настоящий `ci-tradein.yml`, сборка покраснела с указанием файла, строки и порта; на безопасной форме молчит. Живая проверка сегодня в момент, когда CI действительно бежал: три сервис-контейнера Postgres, все в `bridge`, портов не публикуют; боевой `tradein-postgres` наружу тоже ничего не выставляет. Остаётся ваше: **должен ли 5432 вообще быть публикуемым на этом хосте, хоть когда-нибудь**. Если нет — гейт можно ужесточить до полного запрета. Если да (например для ручного доступа) — надо назвать условие, при котором это допустимо, иначе гейт рано или поздно отключат ради разовой задачи. ### 10. Потолок системного журнала — правка в конфигурации хоста `/etc/systemd/journald.conf` пуст: секция есть, все параметры закомментированы, drop-in нет. Журнал сейчас **2.4 ГБ**. Значение имеет не размер, а умолчание `SystemKeepFree` — оно держит 15% файловой системы свободными и при их исчерпании **перестаёт писать**. Для 145 ГБ порог около **21.75 ГБ свободного**; сейчас свободно 28 ГБ, то есть запас **6 ГБ**, а не 28. Отсюда неприятное свойство: вчерашняя правка «логи переживают пересоздание контейнера» имеет **необъявленную зависимость от свободного места**. Когда диск подойдёт к порогу, отказ будет выглядеть как «логов за вчера почему-то нет» — ровно тот симптом, ради устранения которого правка делалась, и в форме, которую трудно связать с причиной. Правка на одну строку (`SystemMaxUse=` + `SystemKeepFree=`), после неё отказ становится предсказуемым: старые записи ротируются, а не отключается запись. **Но это системная конфигурация хоста, а не наш код** — скажите слово, и сделаю. Оговорка, чтобы не читалось тревожнее, чем есть: **диск не убегает**. Резервные копии (11 ГБ) ротируются корректно, ровно недельное окно; дамп основной БД вырос на 27 МБ за шесть суток. При 28 ГБ свободного и таком темпе запас — порядка двух лет. Разбор в #2761. --- ## Поправка к формулировке пункта 7 По разбору он **стал хуже**: узел `asocks-mobile-3` выключился, узлов общего назначения теперь **два**, а не три. И отдельно про пункт 10 из прежней нумерации — обещанная причина пришла и оказалась не той: `AvitoBlockedError: HTTP 403 (5 из 5)`, `ban_kind=platform`. Это отказ площадки, а не транспортный отказ прокси. К токену ASOCKS сводится только косвенно, через репутацию адресов; **прямого доказательства нет**, и я не буду делать вид, что оно есть.
Author
Collaborator

11. Смержить PR #2786 — и раньше, чем #2754

Правка управляющего контура, самомерж по ней запрещён, поэтому лежит открытой и зелёной (8/8): #2786

Порядок важен и в одну сторону. Сначала #2786, потом #2754. После мержа #2786 ваш PR #2754 станет красным на коллизии номера 234 — это и есть цель, а не побочный эффект: сейчас он зелёный при занятом номере. Останется переименовать файл (свободен 240) и снять хунк манифеста — файла больше не будет.

Почему сторож пропускал дрейф — причина оказалась не та, что я предполагал

Я думал, что тест смотрит только файлы из диффа. Нет: он вообще не знает про дифф, это glob по каталогу.

Настоящая причина хуже. «Новым» тест считал файл, которого нет в манифесте, а новые файлы от манифеста явно освобождены — решением, записанным в его собственном докстринге. Значит забытое имя и настоящая новая миграция для него неразличимы по построению. Покраснеть от дрейфа он не мог никогда, ни в какой ветке. Это не пропуск проверки, а её штатное исключение, накрывающее ровно тот случай, ради которого проверка заведена.

Прогон на main сегодня: 228 файлов, 213 имён, 15 не дописано (за сутки выросло с 13) → 4 passed.

Решение: манифеста больше нет

Он служил двум инвариантам, и оба выводимы из git напрямую — не переименовывать применённое (эталон: точка ветвления) и не переиспользовать номер (эталон: полный origin/main). Вариант «файл фиксирует состояние прода» отпал: применённое на проде и есть содержимое main, потому что деплой гоняет каждый data/sql/*.sql под ON_ERROR_STOP. Манифест был ручной копией git ls-tree, всегда отстающей.

Дрейфовать больше нечему. 15 недостающих имён намеренно не дописаны — дописать их значило бы получить то же самое ещё через сутки.

Сторож проверен на восьми сломанных входах, включая ваш PR #2754 как есть: красный, с называнием обоих файлов. На старом гейте то же дерево — зелёное. Ветка от 30.07 с 43 чужими миграциями в main и без своих правок — зелёная, как и требовалось.


Отдельно: зелёная галка на открытом PR значит меньше, чем кажется

Побочная находка того же разбора, и она касается всех открытых PR, не только этого.

В нашем Forgejo нет refs/pull/N/merge — замерено: 1620 ссылок */head, ноль */merge. CI собирает голову ветки, а не результат слияния с текущим main. Перепрогона при движении main не бывает.

Отсюда и коллизия: #2754 отзеленел 06.08 в 19:53, а номер 234 занял чужой мерж в 23:18. Галка осталась зелёной и сама об этом не узнала.

Практически: перед мержем PR, отзеленевшего не сегодня, стоит перезапустить проверки — особенно если правка трогает номера миграций, схему или общие файлы. Чем дольше PR открыт, тем меньше значит его галка.

Прод при этом не затрагивается ничем из перечисленного: _manifest_applied.txt не *.sql, ни цикл деплоя, ни поднятие схемы в CI его не читают. Откат — обычный git revert.

## 11. Смержить PR #2786 — и **раньше**, чем #2754 Правка управляющего контура, самомерж по ней запрещён, поэтому лежит открытой и зелёной (8/8): https://git.gendsgn.ru/lekss361/gendesign/pulls/2786 Порядок важен и в одну сторону. **Сначала #2786, потом #2754.** После мержа #2786 ваш PR #2754 станет красным на коллизии номера 234 — это и есть цель, а не побочный эффект: сейчас он зелёный при занятом номере. Останется переименовать файл (свободен 240) и снять хунк манифеста — файла больше не будет. ### Почему сторож пропускал дрейф — причина оказалась не та, что я предполагал Я думал, что тест смотрит только файлы из диффа. Нет: он вообще не знает про дифф, это `glob` по каталогу. Настоящая причина хуже. «Новым» тест считал файл, **которого нет в манифесте**, а новые файлы от манифеста явно освобождены — решением, записанным в его собственном докстринге. Значит **забытое имя и настоящая новая миграция для него неразличимы по построению**. Покраснеть от дрейфа он не мог никогда, ни в какой ветке. Это не пропуск проверки, а её штатное исключение, накрывающее ровно тот случай, ради которого проверка заведена. Прогон на main сегодня: 228 файлов, 213 имён, **15 не дописано** (за сутки выросло с 13) → `4 passed`. ### Решение: манифеста больше нет Он служил двум инвариантам, и оба выводимы из git напрямую — не переименовывать применённое (эталон: точка ветвления) и не переиспользовать номер (эталон: полный origin/main). Вариант «файл фиксирует состояние прода» отпал: применённое на проде и есть содержимое main, потому что деплой гоняет каждый `data/sql/*.sql` под `ON_ERROR_STOP`. Манифест был ручной копией `git ls-tree`, всегда отстающей. Дрейфовать больше нечему. 15 недостающих имён намеренно не дописаны — дописать их значило бы получить то же самое ещё через сутки. Сторож проверен **на восьми сломанных входах**, включая ваш PR #2754 как есть: красный, с называнием обоих файлов. На старом гейте то же дерево — зелёное. Ветка от 30.07 с 43 чужими миграциями в main и без своих правок — зелёная, как и требовалось. --- ## Отдельно: зелёная галка на открытом PR значит меньше, чем кажется Побочная находка того же разбора, и она касается всех открытых PR, не только этого. В нашем Forgejo **нет `refs/pull/N/merge`** — замерено: 1620 ссылок `*/head`, ноль `*/merge`. CI собирает **голову ветки**, а не результат слияния с текущим main. Перепрогона при движении main не бывает. Отсюда и коллизия: **#2754 отзеленел 06.08 в 19:53, а номер 234 занял чужой мерж в 23:18.** Галка осталась зелёной и сама об этом не узнала. Практически: перед мержем PR, отзеленевшего не сегодня, стоит перезапустить проверки — особенно если правка трогает номера миграций, схему или общие файлы. Чем дольше PR открыт, тем меньше значит его галка. Прод при этом не затрагивается ничем из перечисленного: `_manifest_applied.txt` не `*.sql`, ни цикл деплоя, ни поднятие схемы в CI его не читают. Откат — обычный `git revert`.
Author
Collaborator

12. Пароль user1 в keychain протух — блокирует проверку роль-гейта

Мелочь, но повторится. При проверке #2782 не удалось пройти полную цепочку Caddy → приложение под не-админом: user1 отклоняется на basic_auth.

Обошли иначе — роль-гейт проверен изнутри контейнера с тем самым заголовком, который подставляет Caddy (403 admin only для pilottest и analysttest), а неподделываемость заголовка — отдельным запросом снаружи (401 при попытке подставить его клиентом). То есть вывод получен, но двумя проверками вместо одной, и единым сквозным запросом не подтверждён.

От вас нужен рабочий пароль не-админа в keychain, либо явное «так и оставить» — тогда мы перестанем считать это дыркой и будем проверять двухступенчато штатно.


Побочно из той же правки: находка крупнее исходной задачи

Разблокировав выпадающий список профилей весов, агент обнаружил, что тот молча врал бы.

Запрос анализа отправлял profile_id без profile_user_id, а резолвер ищет профиль как get_profile(db, user_id, profile_id) — при пустом владельце условие не выполняется, веса тихо падают на системные, а ответ рапортует weights_profile.source = "profile".

Замер на проде: profile_id=1 без владельца → вес трамвайной остановки −0.5 вместо −0.4 из профиля. Пользователь видел бы ползунки одного профиля и оценку по другим весам.

Это ровно тема эпика #2674: метка утверждает то, чего не было. Починено в том же PR, проверено живым запросом (source: profile, tram_stop: −0.4).

И ещё: единственный сохранённый профиль весов создан 15.05.2026 — то есть фичей пользовались до #442, и с тех пор она была отрезана от владельца почти три месяца.

## 12. Пароль `user1` в keychain протух — блокирует проверку роль-гейта Мелочь, но повторится. При проверке #2782 не удалось пройти полную цепочку Caddy → приложение под не-админом: `user1` отклоняется на basic_auth. Обошли иначе — роль-гейт проверен изнутри контейнера с тем самым заголовком, который подставляет Caddy (`403 admin only` для `pilottest` и `analysttest`), а неподделываемость заголовка — отдельным запросом снаружи (`401` при попытке подставить его клиентом). То есть **вывод получен, но двумя проверками вместо одной**, и единым сквозным запросом не подтверждён. От вас нужен рабочий пароль не-админа в keychain, либо явное «так и оставить» — тогда мы перестанем считать это дыркой и будем проверять двухступенчато штатно. --- ## Побочно из той же правки: находка крупнее исходной задачи Разблокировав выпадающий список профилей весов, агент обнаружил, что тот **молча врал бы**. Запрос анализа отправлял `profile_id` без `profile_user_id`, а резолвер ищет профиль как `get_profile(db, user_id, profile_id)` — при пустом владельце условие не выполняется, веса тихо падают на системные, **а ответ рапортует `weights_profile.source = "profile"`**. Замер на проде: `profile_id=1` без владельца → вес трамвайной остановки `−0.5` вместо `−0.4` из профиля. Пользователь видел бы ползунки одного профиля и оценку по другим весам. Это ровно тема эпика #2674: метка утверждает то, чего не было. Починено в том же PR, проверено живым запросом (`source: profile, tram_stop: −0.4`). И ещё: единственный сохранённый профиль весов создан **15.05.2026** — то есть фичей пользовались до #442, и с тех пор она была отрезана от владельца почти три месяца.
Author
Collaborator

13. Включить log_lock_waits — иначе о следующей блокировке мы снова узнаем случайно

Сегодня деплой trade-in стоял два часа: миграция ждала монопольную блокировку, а держал её чужой ручной бэктест. Четыре смерженных PR не доехали до прода.

Ни одна секунда этого ожидания нигде не записана. Мы узнали о нём только потому, что смотрели pg_stat_activity руками. Замер настроек боевой БД:

deadlock_timeout            1000 ms   default
log_lock_waits              off       default
lock_timeout                0         default
log_min_duration_statement  -1        default

log_lock_waits = off означает: ожидание блокировки дольше deadlock_timeout не пишется в журнал вообще. При включённом — каждое ожидание дольше секунды попадёт в журнал с указанием, кто держит и кто ждёт. Это ровно тот различитель, поиск которого сегодня занял час.

Правка одной строки в конфигурации боевого Postgres, требует перечитывания конфигурации. Мандат у меня на чтение, поэтому не трогал — скажите слово, и сделаю (либо сделайте сами, ALTER SYSTEM SET log_lock_waits = on; SELECT pg_reload_conf(); — рестарт не нужен).

Оговорка: это включает запись, а не защиту. Защита уже сделана и смержена — конвенция lock_timeout на блокирующий DDL с гейтом в CI (#2791). Но конвенция ловит наши миграции, а журнал покажет любое ожидание, включая чужие ручные сессии.

Сопутствующее, тоже про наблюдаемость

log_min_duration_statement = -1 — медленные запросы не логируются вовсе. Бэктест, из-за которого всё встало, шёл два часа пять минут и в журнале не оставил ни строки. Не настаиваю: включать это на боевой БД без порога — верный способ утопить журнал. Но пороговое значение (скажем, 30 с) стоило бы обсудить отдельно.


Пайплайн разблокирован, состояние на 14:0x MSK

Миграция сноса дубля индекса откачена из main (PR #2792) — она не применена ни на одном стенде, откат вернул ровно прежнее состояние. Все пять контейнеров trade-in пересозданы, running == :latest, четыре застрявших PR доехали.

Снос дубля не потерян: #2793 с готовым текстом и критерием «таблица тиха» (pg_locks по trade_in_estimates = 0), записанным заранее. Файл вернётся уже со строкой lock_timeout, иначе новый гейт уронит CI — он же станет первым настоящим входом этого гейта.

## 13. Включить `log_lock_waits` — иначе о следующей блокировке мы снова узнаем случайно Сегодня деплой trade-in стоял **два часа**: миграция ждала монопольную блокировку, а держал её чужой ручной бэктест. Четыре смерженных PR не доехали до прода. **Ни одна секунда этого ожидания нигде не записана.** Мы узнали о нём только потому, что смотрели `pg_stat_activity` руками. Замер настроек боевой БД: ``` deadlock_timeout 1000 ms default log_lock_waits off default lock_timeout 0 default log_min_duration_statement -1 default ``` `log_lock_waits = off` означает: ожидание блокировки дольше `deadlock_timeout` не пишется в журнал вообще. При включённом — каждое ожидание дольше секунды попадёт в журнал с указанием, кто держит и кто ждёт. Это ровно тот различитель, поиск которого сегодня занял час. Правка одной строки в конфигурации боевого Postgres, требует перечитывания конфигурации. **Мандат у меня на чтение, поэтому не трогал** — скажите слово, и сделаю (либо сделайте сами, `ALTER SYSTEM SET log_lock_waits = on; SELECT pg_reload_conf();` — рестарт не нужен). Оговорка: это включает запись, а не защиту. Защита уже сделана и смержена — конвенция `lock_timeout` на блокирующий DDL с гейтом в CI (#2791). Но конвенция ловит **наши** миграции, а журнал покажет любое ожидание, включая чужие ручные сессии. ### Сопутствующее, тоже про наблюдаемость `log_min_duration_statement = -1` — медленные запросы не логируются вовсе. Бэктест, из-за которого всё встало, шёл **два часа пять минут** и в журнале не оставил ни строки. Не настаиваю: включать это на боевой БД без порога — верный способ утопить журнал. Но пороговое значение (скажем, 30 с) стоило бы обсудить отдельно. --- ## Пайплайн разблокирован, состояние на 14:0x MSK Миграция сноса дубля индекса **откачена из main** (PR #2792) — она не применена ни на одном стенде, откат вернул ровно прежнее состояние. Все пять контейнеров trade-in пересозданы, `running == :latest`, четыре застрявших PR доехали. Снос дубля не потерян: [#2793](https://git.gendsgn.ru/lekss361/gendesign/issues/2793) с готовым текстом и критерием «таблица тиха» (`pg_locks` по `trade_in_estimates` = 0), записанным заранее. Файл вернётся уже со строкой `lock_timeout`, иначе новый гейт уронит CI — он же станет первым настоящим входом этого гейта.
Author
Collaborator

Поправка к пункту 1: слияний было не 6, а 821 — и это сработала связка, а не ошибка

07.08 я поправил вам «93 → 6 домов». Прогон 08.08 04:15 удалил 821 дом (762 кластера). Обе прежние цифры устарели, и вот почему — механизм, а не сбой.

Причина: мой же перенос координат (#2771), смерженный 07.08 днём. Когда я мерил «6», у 1024 пар-кандидатов не было координат, и гео-ограждение их не оценивало — молчало. Перенос дал этим домам координаты из их объявлений (1382 дома получили geom). К ночному прогону ограждению стало что сравнивать, и 821 пара прошла проверку.

Это дословно то, что я обещал в #2771: перенос координат «даёт ограждению возможность оценить пары», а не «разблокирует N слияний». Я специально не называл число заранее — и хорошо, потому что оно оказалось не 6 и не 93.

Все 821 слияния геометрически здоровы — проверил поимённо:

проверка результат
дальше 250 м (было бы ошибкой) 0
максимум расстояния 243.8 м
медиана расстояния 2.5 м
проход только канон-адрес, гео-ограждение включено
со снимком для отката 821 из 821

То есть ни одного склеивания домов из разных городов: всё в пределах ограждения 250 м, которое для области-66 (города за километры друг от друга) означает «одно здание». И каждое слияние поимённо обратимо через журнал #2740 — снимок и проигравшего, и победителя сохранён у всех 821.

Что это меняет для решения по пункту 1. Разрушительность, которой вы опасались, реализовалась — 821 запись удалена, — но в форме, которую вы же и сделали безопасной: обратимой и внутри ограждения. Если хотите просмотреть глазами, это уже не «6 пар за минуты», а выборка из 821; я проверил распределение (всё <250 м) вместо поштучного просмотра. Если что-то смущает — скажите, откачу любой поднабор по журналу.

Отдельно закрою один ваш вопрос из #2690: правило выбора победителя вы называли дефектным («ставит дом без объявлений первым»). В этих 821 слияниях 762 победителя, и сортировка сначала берёт дома с geom и с объявлениями — то есть на практике победителем стал более полный дом. Но это стоит проверить отдельным замером, прежде чем считать #2690 закрытым; не объявляю.

## Поправка к пункту 1: слияний было не 6, а 821 — и это сработала связка, а не ошибка 07.08 я поправил вам «93 → 6 домов». Прогон 08.08 04:15 удалил **821 дом** (762 кластера). Обе прежние цифры устарели, и вот почему — механизм, а не сбой. **Причина: мой же перенос координат (#2771), смерженный 07.08 днём.** Когда я мерил «6», у 1024 пар-кандидатов не было координат, и гео-ограждение их не оценивало — молчало. Перенос дал этим домам координаты из их объявлений (1382 дома получили geom). К ночному прогону ограждению стало **что** сравнивать, и 821 пара прошла проверку. Это дословно то, что я обещал в #2771: перенос координат «даёт ограждению возможность оценить пары», а не «разблокирует N слияний». Я специально не называл число заранее — и хорошо, потому что оно оказалось не 6 и не 93. **Все 821 слияния геометрически здоровы** — проверил поимённо: | проверка | результат | |---|---| | дальше 250 м (было бы ошибкой) | **0** | | максимум расстояния | 243.8 м | | медиана расстояния | 2.5 м | | проход | только канон-адрес, гео-ограждение включено | | со снимком для отката | **821 из 821** | То есть ни одного склеивания домов из разных городов: всё в пределах ограждения 250 м, которое для области-66 (города за километры друг от друга) означает «одно здание». И каждое слияние **поимённо обратимо** через журнал #2740 — снимок и проигравшего, и победителя сохранён у всех 821. **Что это меняет для решения по пункту 1.** Разрушительность, которой вы опасались, реализовалась — 821 запись удалена, — но в форме, которую вы же и сделали безопасной: обратимой и внутри ограждения. Если хотите просмотреть глазами, это уже не «6 пар за минуты», а выборка из 821; я проверил распределение (всё <250 м) вместо поштучного просмотра. Если что-то смущает — скажите, откачу любой поднабор по журналу. Отдельно закрою один ваш вопрос из #2690: правило выбора победителя вы называли дефектным («ставит дом без объявлений первым»). В этих 821 слияниях 762 победителя, и сортировка сначала берёт дома **с** geom и **с** объявлениями — то есть на практике победителем стал более полный дом. Но это стоит проверить отдельным замером, прежде чем считать #2690 закрытым; не объявляю.
Author
Collaborator

Уточнение к пункту 11: моя формулировка про сторожа была шире факта

Я написал, что старый сторож манифеста не мог покраснеть от дрейфа никогда, ни в какой ветке. Проверка на настоящих входах показала, что это шире правды.

Контрпример прогнан: добавили на main файл 238_probe_dup.sql при забытом в манифесте 238_listings_ceiling_height_unify.sql — старый сторож покраснел: «префикс 238 уже у нового 238_listings_ceiling_height_unify.sql». Оба файла для него «новые», и ветка, амнистирующая новые файлы, их же и ловит на коллизии.

Слепая зона у него одна и уже, чем я сказал: файла нет в дереве ветки вовсе. Тогда сравнивать не с чем.

Сам вывод остаётся: список не краснеет от собственного отставания, поэтому дрейф копится. Замер сегодня — 216 имён против 232 файлов, отставание выросло 13 → 15 → 16 за трое суток. Но формулировку «не мог покраснеть никогда» снимаю: она приписывала сторожу больше слепоты, чем у него есть.

Про порядок мержа — совет был верен по времени, просто вышло иначе

Для протокола, чтобы не осталось впечатления, будто я советовал задним числом: пункт 11 написан 07.08 в 10:11 UTC, #2754 смержен в 13:08, то есть тремя часами позже. Совет был своевременным.

Дальше сложилось так: #2754 поехал первым, и коллизию номера 234 поймал человек — вы переименовали 234 → 240 руками в e6591a45 (15:31). Сторож при этом молчал. То есть предсказание «после мержа #2786 ваш PR покраснеет» не сбылось не потому, что было неверным, а потому, что порядок оказался обратным и цену заплатили ручной работой.

Это, кстати, лучший довод за пункт 11, чем мой исходный: коллизия реально случилась и стоила ручного разбора — ровно того, что новый сторож ловит автоматически.

PR #2786 готов к мержу

Конфликт modify/delete по манифесту разрешён удалением. Проверено, что за трое суток в main не появилось ни одного читателя файла (git log -S вне самого файла пуст); новый lock-timeout-сторож тоже ходит по glob("*.sql").

Синхронизация сделана merge-коммитом, а не rebase — rebase потребовал бы --force в общую ветку. Побочный плюс существенный: голова ветки физически содержит слияние с текущим main, поэтому её галка честно про слияние, а не про голову ветки, как обычно у нас бывает.

Шесть проб сторожа, каждая на настоящем входе:

проба ожидание факт
новый файл с номером 253, занятым в main RED RED
переименование применённой 001_* RED RED
удаление применённой 233_payments.sql RED RED
живая ветка #2546 от 26.07, main ушёл на +48 миграций, своих правок ноль GREEN GREEN
она же берёт «следующий свободный» 192, занятый в main RED RED
путь к эталону разъехался RED, не вакуумный зелёный RED «была бы вакуумно-зелёной»

Четвёртая проба — та, ради которой вы просили осторожности: ветка недельной давности без своих правок не краснеет, значит сторож не отключат через неделю. И она не вакуумная — то же самое дерево краснеет в пятой пробе.

CI 8/8, mergeable: true, в логе 4086 passed, 0 skipped — сторож исполнился, а не пропустился.

Окно сейчас чистое: из открытых PR (#2546, #2661, #2751, #2794) ни один не трогает data/sql и ни один не трогает манифест. Конфликт при мерже не достанется никому.

## Уточнение к пункту 11: моя формулировка про сторожа была шире факта Я написал, что старый сторож манифеста **не мог покраснеть от дрейфа никогда, ни в какой ветке**. Проверка на настоящих входах показала, что это шире правды. Контрпример прогнан: добавили на main файл `238_probe_dup.sql` при **забытом** в манифесте `238_listings_ceiling_height_unify.sql` — старый сторож **покраснел**: «префикс 238 уже у нового 238_listings_ceiling_height_unify.sql». Оба файла для него «новые», и ветка, амнистирующая новые файлы, их же и ловит на коллизии. **Слепая зона у него одна и уже, чем я сказал:** файла нет в дереве ветки вовсе. Тогда сравнивать не с чем. Сам вывод остаётся: список не краснеет **от собственного отставания**, поэтому дрейф копится. Замер сегодня — **216 имён против 232 файлов**, отставание выросло 13 → 15 → 16 за трое суток. Но формулировку «не мог покраснеть никогда» снимаю: она приписывала сторожу больше слепоты, чем у него есть. ## Про порядок мержа — совет был верен по времени, просто вышло иначе Для протокола, чтобы не осталось впечатления, будто я советовал задним числом: пункт 11 написан **07.08 в 10:11 UTC**, #2754 смержен в **13:08**, то есть тремя часами позже. Совет был своевременным. Дальше сложилось так: #2754 поехал первым, и коллизию номера 234 **поймал человек** — вы переименовали 234 → 240 руками в `e6591a45` (15:31). Сторож при этом молчал. То есть предсказание «после мержа #2786 ваш PR покраснеет» не сбылось не потому, что было неверным, а потому, что порядок оказался обратным и цену заплатили ручной работой. Это, кстати, лучший довод за пункт 11, чем мой исходный: коллизия **реально случилась** и стоила ручного разбора — ровно того, что новый сторож ловит автоматически. ## PR #2786 готов к мержу Конфликт `modify/delete` по манифесту разрешён удалением. Проверено, что за трое суток в main не появилось ни одного читателя файла (`git log -S` вне самого файла пуст); новый lock-timeout-сторож тоже ходит по `glob("*.sql")`. Синхронизация сделана **merge-коммитом, а не rebase** — rebase потребовал бы `--force` в общую ветку. Побочный плюс существенный: голова ветки физически содержит слияние с текущим main, поэтому **её галка честно про слияние**, а не про голову ветки, как обычно у нас бывает. Шесть проб сторожа, каждая на настоящем входе: | проба | ожидание | факт | |---|---|---| | новый файл с номером 253, занятым в main | RED | **RED** | | переименование применённой `001_*` | RED | **RED** | | удаление применённой `233_payments.sql` | RED | **RED** | | **живая** ветка #2546 от 26.07, main ушёл на +48 миграций, своих правок ноль | GREEN | **GREEN** | | она же берёт «следующий свободный» 192, занятый в main | RED | **RED** | | путь к эталону разъехался | RED, не вакуумный зелёный | **RED** «была бы вакуумно-зелёной» | Четвёртая проба — та, ради которой вы просили осторожности: ветка недельной давности без своих правок не краснеет, значит сторож не отключат через неделю. И она не вакуумная — **то же самое дерево** краснеет в пятой пробе. CI 8/8, `mergeable: true`, в логе `4086 passed, 0 skipped` — сторож исполнился, а не пропустился. **Окно сейчас чистое:** из открытых PR (#2546, #2661, #2751, #2794) **ни один** не трогает `data/sql` и ни один не трогает манифест. Конфликт при мерже не достанется никому.
Author
Collaborator

14. Решение по PR #2816 — правка двигает цену, поэтому она за вами

Дефект по #2677 подтверждён, и он в основании сравнения: медиана домножается на коэффициент ремонта, а домовой якорь — нет. Проверил чтением кода на origin/main: estimator.py:2690 применяет коэффициент к медиане, диапазону и цене за метр; якорь приходит из _fetch_house_imv_anchor как есть.

Следствие: порог «якорь выше медианы в 1.15 раза» для клиента с ремонтом «требует ремонта» фактически превращается в 1.081, а подмешивание с весом 0.5 возвращает половину поправки на ремонт обратно.

Реализованный эффект сегодня — ноль рублей

Сработавших подмешиваний за 1061 оценку — 0. Ноль подтверждён вторым, независимым прибором: следом в колонке пояснений, которая доказуемо умеет заполняться (там же 174 заметки про ремонт, 269 про «тот же дом», 456 про ближайшее окружение).

У нуля есть причина, и она — «заблокировано выше по потоку»: все 19 кандидатов гасит существующий гейт. То есть механизм сегодня не влияет на цену вообще.

Контрфакт: что было бы, если бы гейт не гасил

оценок сдвиг
«требует ремонта» 9 −3.3…−9.8 %, медиана −7.9 %−4.13 млн ₽
«хороший ремонт» 1 +9.6 % → +0.47 млн ₽
остальные 9 ровно 0

Проверка направления на известных объектах — половина не прошла, и это сказано прямо

Понижающая половина подтвердилась: дом на Софьи Перовской 119 («требует ремонта») уходит со 100 411 на 90 566 ₽/м² при медиане 143 реальных сделок ≈ 91 300. Ближе к правде.

Повышающая — нет. Дом на Гаршина 3/2 («хороший ремонт») уходит со 153 629 на 168 324 ₽/м², тогда как 75-й перцентиль сделок — 165 479. Перелёт.

Один объект — не приговор, и перцентиль не потолок. Но проверка на заведомо известном объекте эту половину не подтвердила, и агент не стал это заглаживать.

Что я рекомендую

Мержить, но зная три вещи: (1) сегодня эффект нулевой, потому что гейт всё гасит — правка страхует будущее, а не меняет настоящее; (2) если гейт когда-нибудь ослабят, понижающая половина обоснована сделками, повышающая — нет; (3) разделять правку на «только понижать» не советую — это внесло бы произвольный сдвиг вниз вместо приведения обеих величин к одной базе.

Альтернатива, если хотите осторожнее: смержить и отдельно обсудить однонаправленность подмешивания — она в конфигурации, а не в этом дефекте.

Опровергнуто по дороге, в том числе мной

  • «дом со скосом в „евро" даст дорогой якорь» — не наступило: из 2674 строк не-cosmetic всего 6;
  • «подмешивается только вверх» — про подмешивание верно, про ремонт нет: «евро» занижается примерно на 5 %;
  • моя предпосылка, что «требует ремонта» срабатывает в шесть раз чаще, — артефакт счёта по оценкам вместо домов: 9 срабатываний это 4 дома, а по домам доли 23.5 / 20 / 19.2 % — разницы нет.

Прод-критерий записан до мержа: 2026-09-10, по маркеру в логах; при нуле срабатываний вердикт будет «повода не было», а не «проверено».

## 14. Решение по PR #2816 — правка двигает цену, поэтому она за вами Дефект по #2677 подтверждён, и он в основании сравнения: **медиана домножается на коэффициент ремонта, а домовой якорь — нет**. Проверил чтением кода на `origin/main`: `estimator.py:2690` применяет коэффициент к медиане, диапазону и цене за метр; якорь приходит из `_fetch_house_imv_anchor` как есть. Следствие: порог «якорь выше медианы в 1.15 раза» для клиента с ремонтом «требует ремонта» фактически превращается в 1.081, а подмешивание с весом 0.5 возвращает половину поправки на ремонт обратно. ### Реализованный эффект сегодня — ноль рублей Сработавших подмешиваний за 1061 оценку — **0**. Ноль подтверждён **вторым, независимым прибором**: следом в колонке пояснений, которая доказуемо умеет заполняться (там же 174 заметки про ремонт, 269 про «тот же дом», 456 про ближайшее окружение). У нуля есть причина, и она — **«заблокировано выше по потоку»**: все 19 кандидатов гасит существующий гейт. То есть механизм сегодня не влияет на цену вообще. ### Контрфакт: что было бы, если бы гейт не гасил | | оценок | сдвиг | |---|---|---| | «требует ремонта» | 9 | −3.3…−9.8 %, медиана **−7.9 %** → **−4.13 млн ₽** | | «хороший ремонт» | 1 | **+9.6 %** → +0.47 млн ₽ | | остальные | 9 | ровно 0 | ### Проверка направления на известных объектах — половина не прошла, и это сказано прямо Понижающая половина подтвердилась: дом на Софьи Перовской 119 («требует ремонта») уходит со 100 411 на **90 566 ₽/м²** при медиане 143 реальных сделок ≈ **91 300**. Ближе к правде. **Повышающая — нет.** Дом на Гаршина 3/2 («хороший ремонт») уходит со 153 629 на **168 324 ₽/м²**, тогда как 75-й перцентиль сделок — 165 479. Перелёт. Один объект — не приговор, и перцентиль не потолок. Но проверка на заведомо известном объекте эту половину **не подтвердила**, и агент не стал это заглаживать. ### Что я рекомендую **Мержить**, но зная три вещи: (1) сегодня эффект нулевой, потому что гейт всё гасит — правка страхует будущее, а не меняет настоящее; (2) если гейт когда-нибудь ослабят, понижающая половина обоснована сделками, повышающая — нет; (3) разделять правку на «только понижать» **не советую** — это внесло бы произвольный сдвиг вниз вместо приведения обеих величин к одной базе. Альтернатива, если хотите осторожнее: смержить и **отдельно** обсудить однонаправленность подмешивания — она в конфигурации, а не в этом дефекте. ### Опровергнуто по дороге, в том числе мной - «дом со скосом в „евро" даст дорогой якорь» — не наступило: из 2674 строк не-`cosmetic` всего **6**; - «подмешивается только вверх» — про подмешивание верно, про ремонт нет: «евро» **занижается** примерно на 5 %; - **моя предпосылка**, что «требует ремонта» срабатывает в шесть раз чаще, — артефакт счёта по оценкам вместо домов: 9 срабатываний это 4 дома, а по домам доли 23.5 / 20 / 19.2 % — разницы нет. Прод-критерий записан до мержа: **2026-09-10**, по маркеру в логах; при нуле срабатываний вердикт будет «повода не было», а не «проверено».
Author
Collaborator

СВОДКА НА 2026-08-10 11:00 UTC — что от вас нужно, по убыванию отдачи

Комментариев накопилось много, поэтому собираю действующее в одном месте. Прежние пункты не отменяю — уточняю статус каждого.

Сделать за минуты, отдача наибольшая

1. Получатель уведомлений в GlitchTip (#2673). Замер сегодня на живой БД:

групп ошибок накоплено 6951
живых за сутки 165
отправлено за всю историю 0
получателей / правил 0 / 0

Сегодняшний случай показывает цену буквально: отказ запросов Объектива (#2812) пролежал в этом ящике незамеченным, и нашёл я его только потому, что полез смотреть накопленное руками. Все сторожа, которые мы за четыре дня починили, кричат в пустоту.

Оговорка та же: первым правилом нельзя делать «слать всё». Топ за сутки — 17 групп блокировок НСПД и 8 групп чужих попыток входа в WordPress, они утопят остальное.

2. Смержить #2786 (гейт номеров миграций). Готов, CI зелёный, конфликтов нет, окно чистое — ни один из открытых PR не трогает миграции. Мержить раньше любого PR с новой миграцией. Дрейф продолжается: 216 имён против 232 файлов.

Решения, где нужен ваш выбор

3. Разделяемая память боевой БД (#2812), PR #2819. Два варианта, оба измерены:

  • A — одна строка в compose, простой ~10 секунд, чинит причину. Внимание: применится первым же деплоем после мержа, момент выбирается моментом мержа. Наименее плохое окно — 01:00–02:30 или 21:00–23:00 МСК.
  • B — отключить параллелизм, простоя нет, чинит симптом ценой ×2.2 на районной форме запроса.

Поправка к моей же оценке срочности: это один инцидент длиной 1.2 секунды, а не «6 отказов за сутки». Но последствие хуже, чем казалось — три из четырёх мест дают тихую пустоту, а не видимую ошибку.

4. Денежная правка якоря (#2677), PR #2816. Сегодня эффект нулевой — существующий гейт всё гасит. Если гейт ослабят: девять оценок вниз на медианных −7.9% (−4.13 млн ₽), одна вверх на +0.47 млн. Понижающая половина подтверждена реальными сделками, повышающая проверку не прошла и об этом сказано в PR. Разделять не советую — внесёт произвольный сдвиг.

5. Фильтр свежести в якоре (#2661). Висит с 05.08, −2.25% к ценам, замерено.

6. Возобновление убитого обхода Авито (#2687). Вчера я деплоем убил первый за пять недель полный обход на третьем часу (35 корзин, 5496 объявлений). Контрольная точка сохранена, но плановый прогон её не подхватывает — нужен ручной запуск с указанием прерванного прогона. Скажите — или сделайте кнопкой.

Учётки и ключи

7. Куки Циана. Из-за них cian_history_backfill молчит 42 дня и честно пишет причину в счётчиках. Сейчас разбираем #2700 — возможно, часть 403 идёт от конкретного узла прокси, а не от площадки; если так, часть починится кодом. Отпишусь.

8. DaData «Стандартизация». Ошибка сама говорит, что делать; токен менять не надо.

9. Токен ASOCKS (#2638). Узлов общего назначения сейчас четыре, ротация ждёт токен.

10. Пароль user1 в keychain протух — блокирует сквозную проверку роль-гейта. Либо новый пароль, либо «так и оставить», и мы перестанем считать это дыркой.

11. Ключ Яндекс-геокодера (#2585) — СНЯТ. Проверено живым запросом: ключ работает, 403 пропал сам. И платить всё равно нечем — геокодер вырезан в июле, цена простоя ноль. От вас ничего не нужно.

Инфраструктура, не срочно

12. log_lock_waits = off — двухчасовое ожидание блокировки 09.08 нигде не записано. Одна строка, перезапуск не нужен.

13. Потолок системного журнала не задан явно; работает умолчание, при котором запись прекращается при нехватке 15% диска. Сейчас запас до порога ~6 ГБ, а не 28.

14. Бэкфилл 1123 адресов — СДЕЛАН, от вас ничего не нужно. Загрязнённых ноль, координаты подтянутся прогоном геокодера в 17:45 UTC.


Для протокола: мои ошибки в этой сводке, исправленные

  • «93 дома удалятся» → на деле 6, а потом 821 (после переноса координат) — все в пределах ограждения и обратимы;
  • «6 отказов за сутки» → один инцидент 1.2 с;
  • «чекпоинт подхватится сам» → не подхватывается, параметр передаётся пустым;
  • «сторож не мог покраснеть никогда» → мог, слепая зона уже;
  • «промах падает на системные веса» → падает на чужой профиль, что хуже;
  • совет мержить #2786 раньше #2754 был своевременным (10:11 против 13:08), просто порядок вышел обратным.
# СВОДКА НА 2026-08-10 11:00 UTC — что от вас нужно, по убыванию отдачи Комментариев накопилось много, поэтому собираю действующее в одном месте. Прежние пункты не отменяю — уточняю статус каждого. ## Сделать за минуты, отдача наибольшая **1. Получатель уведомлений в GlitchTip (#2673).** Замер сегодня на живой БД: | | | |---|---| | групп ошибок накоплено | **6951** | | живых за сутки | 165 | | **отправлено за всю историю** | **0** | | получателей / правил | **0 / 0** | Сегодняшний случай показывает цену буквально: отказ запросов Объектива (#2812) пролежал в этом ящике незамеченным, и нашёл я его только потому, что полез смотреть накопленное руками. Все сторожа, которые мы за четыре дня починили, кричат в пустоту. Оговорка та же: первым правилом нельзя делать «слать всё». Топ за сутки — 17 групп блокировок НСПД и 8 групп чужих попыток входа в WordPress, они утопят остальное. **2. Смержить #2786 (гейт номеров миграций).** Готов, CI зелёный, конфликтов нет, окно чистое — ни один из открытых PR не трогает миграции. Мержить **раньше** любого PR с новой миграцией. Дрейф продолжается: 216 имён против 232 файлов. ## Решения, где нужен ваш выбор **3. Разделяемая память боевой БД (#2812), PR #2819.** Два варианта, оба измерены: - **A** — одна строка в compose, простой **~10 секунд**, чинит причину. Внимание: применится **первым же деплоем после мержа**, момент выбирается моментом мержа. Наименее плохое окно — 01:00–02:30 или 21:00–23:00 МСК. - **B** — отключить параллелизм, простоя нет, чинит симптом ценой **×2.2** на районной форме запроса. Поправка к моей же оценке срочности: это **один инцидент длиной 1.2 секунды**, а не «6 отказов за сутки». Но последствие хуже, чем казалось — три из четырёх мест дают **тихую пустоту**, а не видимую ошибку. **4. Денежная правка якоря (#2677), PR #2816.** Сегодня эффект **нулевой** — существующий гейт всё гасит. Если гейт ослабят: девять оценок вниз на медианных −7.9% (**−4.13 млн ₽**), одна вверх на +0.47 млн. Понижающая половина подтверждена реальными сделками, **повышающая проверку не прошла** и об этом сказано в PR. Разделять не советую — внесёт произвольный сдвиг. **5. Фильтр свежести в якоре (#2661).** Висит с 05.08, −2.25% к ценам, замерено. **6. Возобновление убитого обхода Авито (#2687).** Вчера я деплоем убил первый за пять недель полный обход на третьем часу (35 корзин, 5496 объявлений). Контрольная точка сохранена, но **плановый прогон её не подхватывает** — нужен ручной запуск с указанием прерванного прогона. Скажите — или сделайте кнопкой. ## Учётки и ключи **7. Куки Циана.** Из-за них `cian_history_backfill` молчит **42 дня** и честно пишет причину в счётчиках. Сейчас разбираем #2700 — возможно, часть 403 идёт от конкретного узла прокси, а не от площадки; если так, часть починится кодом. Отпишусь. **8. DaData «Стандартизация».** Ошибка сама говорит, что делать; токен менять не надо. **9. Токен ASOCKS (#2638).** Узлов общего назначения сейчас четыре, ротация ждёт токен. **10. Пароль `user1` в keychain протух** — блокирует сквозную проверку роль-гейта. Либо новый пароль, либо «так и оставить», и мы перестанем считать это дыркой. **11. Ключ Яндекс-геокодера (#2585) — СНЯТ.** Проверено живым запросом: ключ **работает**, 403 пропал сам. И платить всё равно нечем — геокодер вырезан в июле, цена простоя **ноль**. От вас ничего не нужно. ## Инфраструктура, не срочно **12. `log_lock_waits = off`** — двухчасовое ожидание блокировки 09.08 нигде не записано. Одна строка, перезапуск не нужен. **13. Потолок системного журнала** не задан явно; работает умолчание, при котором запись **прекращается** при нехватке 15% диска. Сейчас запас до порога ~6 ГБ, а не 28. **14. Бэкфилл 1123 адресов — СДЕЛАН**, от вас ничего не нужно. Загрязнённых ноль, координаты подтянутся прогоном геокодера в 17:45 UTC. --- ## Для протокола: мои ошибки в этой сводке, исправленные - «93 дома удалятся» → на деле 6, а потом 821 (после переноса координат) — все в пределах ограждения и обратимы; - «6 отказов за сутки» → один инцидент 1.2 с; - «чекпоинт подхватится сам» → не подхватывается, параметр передаётся пустым; - «сторож не мог покраснеть никогда» → мог, слепая зона уже; - «промах падает на системные веса» → падает на чужой профиль, что хуже; - совет мержить #2786 раньше #2754 был **своевременным** (10:11 против 13:08), просто порядок вышел обратным.
Author
Collaborator

Уточнение пункта 7 (куки Циана): он был сформулирован ШИРЕ правды

Я писал, что из-за протухших кук Циана стоят detail-страницы и домовые поля. Неверно. Разбор #2700 развёл два разных механизма, и куки нужны только одному.

Различающая проба: дело было в узле, а не в площадке

Один и тот же detail-URL, тот же боевой код, менялся только узел прокси:

узел статус размер маркеры
1 residential 403 21 564 cian_waf_block
9 mobile 200 617 352 нет
10 mobile 200 617 355 нет
11 mobile 200 617 407 нет

Площадка отдаёт 200 трём узлам из четырёх. Забанена не мы, а пара «узел × Циан».

И detail-страница авторизации не требует вовсе: три успешных ответа получены без единой куки, а функция запроса куки не отправляет в принципе — проверил чтением кода на актуальной ветке, ни одного упоминания. Совпадение по времени с протуханием кук 30 июня причиной не было.

Один корень на три симптома

403 гасился в «вернуть пусто», наружу не выходило ничего. Тот же путь сообщал пулу «узел здоров» на отбитый узел — поэтому пул продолжал выдавать его Циану пятнадцать суток. Отсюда же и нулевые счётчики ошибок, которые я считал отдельным дефектом.

Detail-страницы ожили сами, ещё до правки

в задаче (25.07) прод 10.08
detail-прогоны 50/50 отказов, 15 суток 10 из 10 успешны
серия дома 0 19
подъезды 0 63
квартир в доме 0 65
тип отопления 0 80
просмотры 0 из 21 951 148

403 прекратились между прогонами 07.08 и 08.08 — то есть снова улучшение не от той правки, которую я бы записал в героини. Причина в другом: узел перестал выдаваться Циану после работ с пулом.

Что от вас всё-таки нужно — и только это

Седьмой источник оценки (cian_valuation) стоит на куках, и они мертвы на стороне Циана. Запрос калькулятора через здоровый узел дал 200 и 352 КБ без маркеров блокировки, но с признаком «не авторизован». То есть сессия истекла у них, а не по нашему сроку — наш expires_at вычислялся как «загрузка + 30 дней», то есть был оценкой, а не фактом.

В базе одна запись, куки от 31 мая. Автоперелогина в проде нет — вход делает скрипт с вашей машины.

Цена простоя, измеренная: с 29.06 по 07.08 выдано 320 оценок без седьмого источника. Что запрос при этом делался, видно по соседу: Яндекс за то же окно написал 107 строк, то есть оценки запрашивались — отказывал именно Циан. Плюс 42 суток без исторического бэкфилла.

Пункт 7 переформулирую так: нужны свежие куки для калькулятора Циана. Detail-страницы и домовые поля в этом не нуждаются и уже работают.

Побочно: 42 прогона врали, и 11 из них не про Циан

Правка #2821 нашла общий класс: прогон с полностью отказавшей фазой помечался успешным. По боевым данным таких 42 из 3293 (1.3%) — 31 у Циана и 11 у Авито, про которые никто не знал.

## Уточнение пункта 7 (куки Циана): он был сформулирован ШИРЕ правды Я писал, что из-за протухших кук Циана стоят detail-страницы и домовые поля. **Неверно.** Разбор #2700 развёл два разных механизма, и куки нужны только одному. ### Различающая проба: дело было в узле, а не в площадке Один и тот же detail-URL, тот же боевой код, менялся только узел прокси: | узел | статус | размер | маркеры | |---|---:|---:|---| | 1 residential | **403** | 21 564 | `cian_waf_block` | | 9 mobile | 200 | 617 352 | нет | | 10 mobile | 200 | 617 355 | нет | | 11 mobile | 200 | 617 407 | нет | Площадка отдаёт 200 **трём узлам из четырёх**. Забанена не мы, а **пара «узел × Циан»**. И detail-страница **авторизации не требует вовсе**: три успешных ответа получены **без единой куки**, а функция запроса куки не отправляет в принципе — проверил чтением кода на актуальной ветке, ни одного упоминания. Совпадение по времени с протуханием кук 30 июня причиной не было. ### Один корень на три симптома 403 гасился в «вернуть пусто», наружу не выходило ничего. Тот же путь сообщал пулу «узел здоров» **на отбитый узел** — поэтому пул продолжал выдавать его Циану **пятнадцать суток**. Отсюда же и нулевые счётчики ошибок, которые я считал отдельным дефектом. ### Detail-страницы ожили сами, ещё до правки | | в задаче (25.07) | прод 10.08 | |---|---|---| | detail-прогоны | 50/50 отказов, 15 суток | **10 из 10 успешны** | | серия дома | 0 | 19 | | подъезды | 0 | 63 | | квартир в доме | 0 | 65 | | тип отопления | 0 | 80 | | просмотры | 0 из 21 951 | 148 | 403 прекратились между прогонами 07.08 и 08.08 — то есть **снова улучшение не от той правки**, которую я бы записал в героини. Причина в другом: узел перестал выдаваться Циану после работ с пулом. ### Что от вас всё-таки нужно — и только это **Седьмой источник оценки (`cian_valuation`) стоит на куках, и они мертвы на стороне Циана.** Запрос калькулятора через здоровый узел дал 200 и 352 КБ без маркеров блокировки, но с признаком **«не авторизован»**. То есть сессия истекла у них, а не по нашему сроку — наш `expires_at` вычислялся как «загрузка + 30 дней», то есть был оценкой, а не фактом. В базе одна запись, куки от 31 мая. Автоперелогина в проде нет — вход делает скрипт с вашей машины. **Цена простоя, измеренная:** с 29.06 по 07.08 выдано **320 оценок без седьмого источника**. Что запрос при этом делался, видно по соседу: Яндекс за то же окно написал 107 строк, то есть оценки запрашивались — отказывал именно Циан. Плюс 42 суток без исторического бэкфилла. **Пункт 7 переформулирую так:** нужны свежие куки **для калькулятора Циана**. Detail-страницы и домовые поля в этом не нуждаются и уже работают. ### Побочно: 42 прогона врали, и 11 из них не про Циан Правка #2821 нашла общий класс: прогон с **полностью отказавшей фазой** помечался успешным. По боевым данным таких 42 из 3293 (1.3%) — 31 у Циана и **11 у Авито**, про которые никто не знал.
Author
Collaborator

Пункт про денежную правку СНЯТ: препятствие исчезло само

PR #2661 висел неделю, потому что стоил −2.25% к сумме выкупа, и это был вопрос политики к вам. Перемер на сегодняшних данных:

05.08 12.08
фильтр якоря −3.63% −1.07%
фильтр знаменателя +1.25% +0.71%
сброс залипшего флага +0.11% +0.46%
итого к сумме выкупа −2.25% +0.09%
оценок теряют якорь 139 из 1014 57 из 1052, и 11 приобретают
рост отказов 79 → 85 нет вовсе: 15 → 15

Цена вопроса упала с −2.25% до девяти сотых процента вверх. Того, ради чего вас спрашивали, больше нет.

Почему сдвинулось — проверил сам

Изменился состав собранных данных. Доля протухших (старше 14 суток) среди активных:

источник сегмент активных протухших доля
avito вторичка 7629 0 0%
domklik вторичка 752 0 0%
cian вторичка 7452 1534 20.6%
yandex вторичка 4202 908 21.6%
cian новостройки 11622 10837 93.2%

И главное: вся протухшая масса на 84% — новостройки, которых защита #1186 в якорь не пускает вовсе. То есть протухшее почти перестало попадать туда, где оно двигало цену.

Своими глазами: первый мой замер дал «65% протухших у Циана» и разошёлся с отчётом — потому что я считал по всем сегментам сразу. По вторичке, которую и берёт якорь, цифры сошлись до десятых.

Направление проверено на реальных сделках

914 оценок сверены с медианой зарегистрированных договоров по тому же дому (в пределах 150 м, за 12 месяцев, с совпадением комнатности):

до правки после
медиана ошибки, все 914 22.81% 21.92%
медиана ошибки на 147, что двигаются ≥5% 22.90% 19.56%
ближе к сделкам / дальше 91 / 56

Там, где правка реально шевелит цену, она шевелит её к сделкам. Оговорка честная: договоры не полностью независимы — сделки кормят коридор и квартальный индекс внутри самого оценщика.

Моя рекомендация

Мержить. Правка перестала стоить денег и при этом измеримо приближает оценку к реальным сделкам. Неделю назад это был размен «точность против суммы», сегодня размена нет.

Оговорка, которая может изменить решение завтра

Число зависит от состава собранных данных и уехало на 2.3 процентных пункта за неделю. Если решать будете не сегодня — замер стоит повторить, оснастка воспроизводима и прогон занимает 25 минут, только чтение.

Опровергнуто по дороге — семь предпосылок, включая заглавную

Кроме уже названных: «протухшие в якорном сегменте на 7.7% дороже живых» — сегодня 3.3%; «648 фантомов завышают знаменатель на 1.28%» — не воспроизводится ни в какую сторону; «окно свежести живёт в одном месте» — с 10.08 их два, и радиусный путь на тонкой выборке расширяет окно до 60 суток, тогда как якорь после мержа останется на 14. Последнее — открытая политика, не дефект: в тонком рынке мы предпочтём 60-дневный пул по радиусу 14-дневному якорю по тому же дому. Стоит решить отдельно.

# Пункт про денежную правку СНЯТ: препятствие исчезло само PR **#2661** висел неделю, потому что стоил **−2.25%** к сумме выкупа, и это был вопрос политики к вам. Перемер на сегодняшних данных: | | 05.08 | **12.08** | |---|---:|---:| | фильтр якоря | −3.63% | −1.07% | | фильтр знаменателя | +1.25% | +0.71% | | сброс залипшего флага | +0.11% | +0.46% | | **итого к сумме выкупа** | **−2.25%** | **+0.09%** | | оценок теряют якорь | 139 из 1014 | **57 из 1052**, и 11 **приобретают** | | рост отказов | 79 → 85 | **нет вовсе**: 15 → 15 | **Цена вопроса упала с −2.25% до девяти сотых процента вверх.** Того, ради чего вас спрашивали, больше нет. ## Почему сдвинулось — проверил сам Изменился состав собранных данных. Доля протухших (старше 14 суток) среди активных: | источник | сегмент | активных | протухших | доля | |---|---|---:|---:|---:| | avito | вторичка | 7629 | **0** | **0%** | | domklik | вторичка | 752 | **0** | **0%** | | cian | вторичка | 7452 | 1534 | 20.6% | | yandex | вторичка | 4202 | 908 | 21.6% | | cian | новостройки | 11622 | 10837 | 93.2% | И главное: **вся протухшая масса на 84% — новостройки**, которых защита #1186 в якорь не пускает вовсе. То есть протухшее почти перестало попадать туда, где оно двигало цену. Своими глазами: первый мой замер дал «65% протухших у Циана» и разошёлся с отчётом — потому что я считал по всем сегментам сразу. По вторичке, которую и берёт якорь, цифры сошлись до десятых. ## Направление проверено на реальных сделках 914 оценок сверены с медианой зарегистрированных договоров по тому же дому (в пределах 150 м, за 12 месяцев, с совпадением комнатности): | | до правки | после | |---|---:|---:| | медиана ошибки, все 914 | 22.81% | **21.92%** | | медиана ошибки на 147, что двигаются ≥5% | 22.90% | **19.56%** | | ближе к сделкам / дальше | — | **91 / 56** | Там, где правка реально шевелит цену, она шевелит её **к сделкам**. Оговорка честная: договоры не полностью независимы — сделки кормят коридор и квартальный индекс внутри самого оценщика. ## Моя рекомендация **Мержить.** Правка перестала стоить денег и при этом измеримо приближает оценку к реальным сделкам. Неделю назад это был размен «точность против суммы», сегодня размена нет. ## Оговорка, которая может изменить решение завтра Число **зависит от состава собранных данных и уехало на 2.3 процентных пункта за неделю**. Если решать будете не сегодня — замер стоит повторить, оснастка воспроизводима и прогон занимает 25 минут, только чтение. ## Опровергнуто по дороге — семь предпосылок, включая заглавную Кроме уже названных: «протухшие в якорном сегменте на 7.7% дороже живых» — сегодня 3.3%; «648 фантомов завышают знаменатель на 1.28%» — не воспроизводится ни в какую сторону; «окно свежести живёт в одном месте» — с 10.08 их два, и радиусный путь на тонкой выборке расширяет окно до 60 суток, тогда как якорь после мержа останется на 14. Последнее — открытая политика, не дефект: в тонком рынке мы предпочтём 60-дневный пул по радиусу 14-дневному якорю по тому же дому. Стоит решить отдельно.
Author
Collaborator

Пересобрано 2026-08-13 00:15 MSK — после дня работы

Шесть правок доехали до прода и проверены кодом в живом контейнере, а не цветом галки. Список для вас сократился и изменился по составу.


ТРЕБУЕТ ВАС (действие в чужом интерфейсе)

1. Получатель уведомлений в GlitchTip — #2673

Прежний довод в силе, и сегодня он стал точнее. Дело не только в отсутствии получателя: интеграция поднята с event_level=ERROR (app/main.py:96), поэтому предупреждение событием не становится в принципе. Всё, что написано уровнем warning, живёт только в логах контейнера, а их сносит каждый деплой.

Проверено сегодня: контейнер поднят, в нём 9 строк лога, ни одной строки оценщика за 168 часов. То есть по логам нельзя задать даже вопрос «сработал ли механизм».

2. Учётные данные Циана — 0 из 2 переменных в окружении прода

Ручка автоперехода написана и покрыта тестами, отвечает 400. Цена уже уплачена: 41 день пропусков сбора истории, 42.5 суток нуля данных. Нынешняя сессия жива до 09.09 — запас 28 суток. Ключи я не подбираю и учётки не завожу.

3. PR #2786 — гейт номеров миграций, управляющий контур

Самомерж по такому PR запрещён правилами. Сегодня расконфликтовал повторно — он ломается каждой новой миграцией, за неделю дважды. CI зелёный на восьми задачах, сливается чисто.

Цена ожидания растёт: пока манифест жив, он остаётся вторым источником правды о номерах миграций — а расхождение этих двух источников PR и чинит.

4. Источник n1 — решение «поддерживаем или закрываем»

Ответить может только владелец. Факты:

расписания у источника НЕТ вообще     0 строк в scrape_schedules
последний сбор                        16.06, успешный, 250 лотов
03.07 deactivate_stale_n1             снял 381 объявление из 382

Деактиватор именно для n1 кто-то написал — значит источник считался поддерживаемым. Объём мал (382 против 51 135 у Авито, 0.4% всего), так что цена вопроса невелика в обе стороны. Но ноль должен иметь причину: если закрываем — деактиватор и разбор надо удалить, чтобы не создавали вид работающей функции; если поддерживаем — расписание отсутствует.


ДВА РЕШЕНИЯ ПО ЧИСЛАМ (код готов, включать вам)

5. Понижать ли доверие к коридору сделок — #2846

Не тронуто намеренно. Число: коридор ADVISORY, порога свежести нет вовсе, у 100% оценок с коридором опорные сделки старше 223 дней, у 8.7% — старше 315. Сегодня подпись стала честной (#2847, на проде), но роль коридора не менялась.

6. Координатный резолв квартала — флаг выключен (#2839, на проде)

Порог 50 м не подтвердился замером: точность 77.7% против 90.9% на 25 м (2648 домов, истина независима — кадастры от DaData по адресу). Флаг estimate_quarter_from_coords_enabled=False, порог затянут до 25 м, критерий приёмки и дата удаления записаны в коде. Включение — ваше решение после замера.


СДЕЛАНО СЕГОДНЯ (проверено на проде числом)

что было стало
ссылки Яндекса на сайты застройщиков (#2838, #2840) 3535 0 из 17 970
второй потребитель тех же ссылок 1777 0
дома, застрявшие в «временной» ошибке (#2843) 1390 без выхода счётчик попыток, возврат в очередь
квартал соседа вместо квартала цели (#2839) 15 из 15 применений снято, MAPE 13.18 → 12.63
подхват контрольной точки (#2845) 433 корзины впустую за 90 суток планировщик подхватывает
возраст сделок на экране (#2847) не показан «по I кв. 2026»

Заведено по ходу: #2841 (преходящий 403 реестра роняет сборку — правка не доезжает молча), #2842 (source_url пишется только при вставке — записанное рассуждение, чинить нечего), #2846, #2848 (осиротевший прогон 6 часов числится идущим).


ЖДУТ СРОКА — критерии записаны ДО факта

когда (UTC) что критерий
13.08 10:27 yandex_detail_backfill url_from_offer_id < 3535. Осторожно: два прогона 12.08 показывают 3535, но они дореформенные (08:08 против деплоя в 15:35)
14.08 15:59 house_imv_backfill число застрявших убывает
16.08 13:37 avito_full_load_exhaustive resume_from=3547, resume_buckets=35. checkpoint_stale ⇒ срок годности выбран узко
04–09.09 предупреждение о протухании Циана если не сработает при непротухших данных — находка жива
12.09 координатный резолв квартала не измерен ⇒ флаг и код удалить, а не оставлять «на вырост»
# Пересобрано 2026-08-13 00:15 MSK — после дня работы Шесть правок доехали до прода и проверены **кодом в живом контейнере**, а не цветом галки. Список для вас сократился и изменился по составу. --- # ТРЕБУЕТ ВАС (действие в чужом интерфейсе) ## 1. Получатель уведомлений в GlitchTip — #2673 Прежний довод в силе, и сегодня он стал точнее. Дело не только в отсутствии получателя: интеграция поднята с `event_level=ERROR` (`app/main.py:96`), поэтому **предупреждение событием не становится в принципе**. Всё, что написано уровнем `warning`, живёт только в логах контейнера, а их сносит каждый деплой. Проверено сегодня: контейнер поднят, в нём 9 строк лога, ни одной строки оценщика за 168 часов. То есть по логам нельзя задать даже вопрос «сработал ли механизм». ## 2. Учётные данные Циана — 0 из 2 переменных в окружении прода Ручка автоперехода написана и покрыта тестами, отвечает 400. Цена уже уплачена: **41 день** пропусков сбора истории, **42.5 суток** нуля данных. Нынешняя сессия жива до **09.09** — запас 28 суток. Ключи я не подбираю и учётки не завожу. ## 3. PR #2786 — гейт номеров миграций, управляющий контур Самомерж по такому PR запрещён правилами. **Сегодня расконфликтовал повторно** — он ломается каждой новой миграцией, за неделю дважды. CI зелёный на восьми задачах, сливается чисто. Цена ожидания растёт: пока манифест жив, он остаётся **вторым источником правды** о номерах миграций — а расхождение этих двух источников PR и чинит. ## 4. Источник n1 — решение «поддерживаем или закрываем» Ответить может только владелец. Факты: ``` расписания у источника НЕТ вообще 0 строк в scrape_schedules последний сбор 16.06, успешный, 250 лотов 03.07 deactivate_stale_n1 снял 381 объявление из 382 ``` Деактиватор именно для n1 кто-то написал — значит источник считался поддерживаемым. Объём мал (382 против 51 135 у Авито, 0.4% всего), так что цена вопроса невелика в обе стороны. Но **ноль должен иметь причину**: если закрываем — деактиватор и разбор надо удалить, чтобы не создавали вид работающей функции; если поддерживаем — расписание отсутствует. --- # ДВА РЕШЕНИЯ ПО ЧИСЛАМ (код готов, включать вам) ## 5. Понижать ли доверие к коридору сделок — #2846 Не тронуто намеренно. Число: коридор ADVISORY, порога свежести нет вовсе, **у 100% оценок с коридором опорные сделки старше 223 дней, у 8.7% — старше 315**. Сегодня подпись стала честной (#2847, на проде), но роль коридора не менялась. ## 6. Координатный резолв квартала — флаг выключен (#2839, на проде) Порог 50 м **не подтвердился замером**: точность 77.7% против 90.9% на 25 м (2648 домов, истина независима — кадастры от DaData по адресу). Флаг `estimate_quarter_from_coords_enabled=False`, порог затянут до 25 м, критерий приёмки и дата удаления записаны в коде. Включение — ваше решение после замера. --- # СДЕЛАНО СЕГОДНЯ (проверено на проде числом) | что | было | стало | |---|---|---| | ссылки Яндекса на сайты застройщиков (#2838, #2840) | 3535 | **0 из 17 970** | | второй потребитель тех же ссылок | 1777 | **0** | | дома, застрявшие в «временной» ошибке (#2843) | 1390 без выхода | счётчик попыток, возврат в очередь | | квартал соседа вместо квартала цели (#2839) | 15 из 15 применений | снято, MAPE 13.18 → **12.63** | | подхват контрольной точки (#2845) | 433 корзины впустую за 90 суток | планировщик подхватывает | | возраст сделок на экране (#2847) | не показан | «по I кв. 2026» | Заведено по ходу: **#2841** (преходящий 403 реестра роняет сборку — правка не доезжает молча), **#2842** (`source_url` пишется только при вставке — записанное рассуждение, чинить нечего), **#2846**, **#2848** (осиротевший прогон 6 часов числится идущим). --- # ЖДУТ СРОКА — критерии записаны ДО факта | когда (UTC) | что | критерий | |---|---|---| | **13.08 10:27** | `yandex_detail_backfill` | `url_from_offer_id` < 3535. Осторожно: два прогона 12.08 показывают 3535, но они **дореформенные** (08:08 против деплоя в 15:35) | | **14.08 15:59** | `house_imv_backfill` | число застрявших убывает | | **16.08 13:37** | `avito_full_load_exhaustive` | `resume_from=3547`, `resume_buckets=35`. `checkpoint_stale` ⇒ срок годности выбран узко | | **04–09.09** | предупреждение о протухании Циана | если не сработает при непротухших данных — находка жива | | **12.09** | координатный резолв квартала | не измерен ⇒ флаг и код удалить, а не оставлять «на вырост» |
Author
Collaborator

Пересобрано 2026-08-13 14:00 MSK

За сутки на прод доехали 17 правок, каждая проверена кодом в живом контейнере. Список для вас сократился и изменился по составу; появилось три новых пункта.


ТРЕБУЕТ ВАС

1. Получатель уведомлений в GlitchTip — #2673

Без изменений и по-прежнему первое по важности. Уточнение со вчера: интеграция поднята с event_level=ERROR, поэтому всё, что написано уровнем warning, событием не становится в принципе.

2. Учётные данные Циана — 0 из 2 переменных в проде

Ручка автоперехода написана и покрыта тестами, отвечает 400. Сессия жива до 09.09 — запас 27 суток. Ключи не подбираю.

3. PR #2786 — гейт номеров миграций (управляющий контур)

Вчера он доказал свою нужность на живом примере: два независимых PR взяли один номер 259. Git этого не видит — имена файлов разные, конфликта нет. Разошлось только потому, что я посмотрел глазами перед мержем. Расконфликтовал повторно, CI зелёный.

4. Источник n1 — «поддерживаем или закрываем»

Расписания нет вообще (0 строк), последний сбор 16.06, 03.07 деактиватор снял 381 объявление из 382. Деактиватор именно для n1 кто-то писал — значит источник считался живым.


НОВОЕ, ТРЕБУЕТ РЕШЕНИЯ

5. Коэффициент «хороший ремонт» — не константа (#2853)

Замер парным ₽/м² внутри одного дома:

эпоха пар премия
1990-2009 240 1.0236
2010+ 641 1.0230
до 1990 435 1.0000

Применяется единая 1.05. В старом фонде она выдумывает надбавку, которой нет. Цена: 73 оценки, 879 млн ₽ суммы медиан, −27.7 млн при переходе на измеренное. Вопрос не «какое число лучше», а «применять ли разные к разным эпохам».

6. Поле district в витрине поиска (#2857)

Три колонки-заглушки убраны (#2858, на проде). Четвёртая — district — доезжает до схемы ответа API и всегда пуста. Либо подключить, либо снять вместе с полем схемы: держать в контракте поле, которое не заполнится, — решение, а не техника.

7. Уборка схемы: 18 колонок на удаление, 9 в вашей зоне (#2674)

Разбор 33 пустых колонок: работы по существу на две, остальное — уборка. Девять входят в публичный контракт market.v_houses и market.v_house_sources, то есть пустота ежесуточно переливается в другой продукт. Удаление любой — изменение внешнего обещания.

8. #2661 — фильтр свежести. Блокер снят дважды и независимо

Ваш прежний стоп-довод «правка стоит −2.25% клиенту» больше не действует: перезамер автора даёт +0.09%, а я обновил ветку до сегодняшнего main и прогнал бэктест-гейт — все денежные метрики совпали побайтно (сверял весь набор, а не первое несовпадение). Направление проверено по 914 сделкам: там, где правка двигает цену, она двигает её к ценам ДКП (22.90% → 19.56% на подвижках ≥5%).

Осталась одна оговорка: фикстура зовёт расчёт напрямую, минуя часть путей, поэтому «метрики не сдвинулись» означает «на покрытых путях».


СДЕЛАНО ЗА СУТКИ (проверено числом)

что было стало
ссылки Яндекса на сайты застройщиков 3535 0 из 17 970
дома, застрявшие в «временной» ошибке 1390 без выхода счётчик попыток + возврат
квартал соседа вместо квартала цели 15 из 15 снято, MAPE 13.18 → 12.63
контрольная точка оборванного прогона 433 корзины впустую / 90 суток подхватывается
возраст сделок на экране не показан «по I кв. 2026»
этаж сделки на экране скрыт у всех 96 974 показан
сторож свежести ориентира недостижим, красен всегда мерит отставание загрузки
проба узла Домклика спрашивала robots.txt спрашивает боевой API

Заведено новых задач с числами: #2841 (преходящий 403 реестра роняет сборку), #2842, #2846, #2848 (осиротевший прогон 6 часов числится идущим), #2853, #2854, #2855, #2857, #2860.


ЖДУТ СРОКА — критерии записаны ДО факта

когда (UTC) что критерий
сегодня 10:27 yandex_detail_backfill url_from_offer_id < 3535
14.08 15:59 house_imv_backfill число застрявших убывает
16.08 13:37 avito_full_load_exhaustive resume_from=3547, resume_buckets=35
до 20.08 проба Домклика (#2856) бан пары узел×domclick с причиной probe:browser в сутки блокировки свипа. Если за неделю ни разу — правка бесполезна
04–09.09 предупреждение о протухании Циана сработает при непротухших данных
12.09 координатный резолв квартала не измерен ⇒ флаг и код удалить

ОДНА ЖИВАЯ ПОЛОМКА, НАЙДЕННАЯ ПОБОЧНО — #2860

yandex_newbuilding_sweep: восемь прогонов подряд «обработано 5, успешно 0» со статусом done и пустым текстом ошибки. Очередь растёт 351 → 389, витрина стоит на 34 строках с 15.07. И последний прогон — 10.08, то есть он ещё и перестал быть суточным.

# Пересобрано 2026-08-13 14:00 MSK За сутки на прод доехали **17 правок**, каждая проверена кодом в живом контейнере. Список для вас сократился и изменился по составу; появилось три новых пункта. --- # ТРЕБУЕТ ВАС ## 1. Получатель уведомлений в GlitchTip — #2673 Без изменений и по-прежнему первое по важности. Уточнение со вчера: интеграция поднята с `event_level=ERROR`, поэтому **всё, что написано уровнем warning, событием не становится в принципе**. ## 2. Учётные данные Циана — 0 из 2 переменных в проде Ручка автоперехода написана и покрыта тестами, отвечает 400. Сессия жива до **09.09** — запас 27 суток. Ключи не подбираю. ## 3. PR #2786 — гейт номеров миграций (управляющий контур) **Вчера он доказал свою нужность на живом примере:** два независимых PR взяли один номер 259. Git этого не видит — имена файлов разные, конфликта нет. Разошлось только потому, что я посмотрел глазами перед мержем. Расконфликтовал повторно, CI зелёный. ## 4. Источник n1 — «поддерживаем или закрываем» Расписания нет вообще (0 строк), последний сбор 16.06, 03.07 деактиватор снял 381 объявление из 382. Деактиватор именно для n1 кто-то писал — значит источник считался живым. --- # НОВОЕ, ТРЕБУЕТ РЕШЕНИЯ ## 5. Коэффициент «хороший ремонт» — не константа (#2853) Замер парным ₽/м² **внутри одного дома**: | эпоха | пар | премия | |---|---:|---:| | 1990-2009 | 240 | 1.0236 | | 2010+ | 641 | 1.0230 | | **до 1990** | **435** | **1.0000** | Применяется единая **1.05**. В старом фонде она выдумывает надбавку, которой нет. Цена: 73 оценки, 879 млн ₽ суммы медиан, −27.7 млн при переходе на измеренное. Вопрос не «какое число лучше», а «применять ли разные к разным эпохам». ## 6. Поле `district` в витрине поиска (#2857) Три колонки-заглушки убраны (#2858, на проде). Четвёртая — `district` — доезжает до схемы ответа API и всегда пуста. Либо подключить, либо снять вместе с полем схемы: держать в контракте поле, которое не заполнится, — решение, а не техника. ## 7. Уборка схемы: 18 колонок на удаление, 9 в вашей зоне (#2674) Разбор 33 пустых колонок: работы по существу на **две**, остальное — уборка. Девять входят в публичный контракт `market.v_houses` и `market.v_house_sources`, то есть пустота ежесуточно переливается в другой продукт. Удаление любой — изменение внешнего обещания. ## 8. #2661 — фильтр свежести. **Блокер снят дважды и независимо** Ваш прежний стоп-довод «правка стоит −2.25% клиенту» больше не действует: перезамер автора даёт **+0.09%**, а я обновил ветку до сегодняшнего main и прогнал бэктест-гейт — **все денежные метрики совпали побайтно** (сверял весь набор, а не первое несовпадение). Направление проверено по 914 сделкам: там, где правка двигает цену, она двигает её **к** ценам ДКП (22.90% → 19.56% на подвижках ≥5%). Осталась одна оговорка: фикстура зовёт расчёт напрямую, минуя часть путей, поэтому «метрики не сдвинулись» означает «на покрытых путях». --- # СДЕЛАНО ЗА СУТКИ (проверено числом) | что | было | стало | |---|---|---| | ссылки Яндекса на сайты застройщиков | 3535 | **0 из 17 970** | | дома, застрявшие в «временной» ошибке | 1390 без выхода | счётчик попыток + возврат | | квартал соседа вместо квартала цели | 15 из 15 | снято, MAPE 13.18 → **12.63** | | контрольная точка оборванного прогона | 433 корзины впустую / 90 суток | подхватывается | | возраст сделок на экране | не показан | «по I кв. 2026» | | **этаж сделки на экране** | **скрыт у всех 96 974** | показан | | сторож свежести ориентира | недостижим, красен всегда | мерит отставание загрузки | | проба узла Домклика | спрашивала robots.txt | спрашивает боевой API | Заведено новых задач с числами: **#2841** (преходящий 403 реестра роняет сборку), **#2842**, **#2846**, **#2848** (осиротевший прогон 6 часов числится идущим), **#2853**, **#2854**, **#2855**, **#2857**, **#2860**. --- # ЖДУТ СРОКА — критерии записаны ДО факта | когда (UTC) | что | критерий | |---|---|---| | **сегодня 10:27** | `yandex_detail_backfill` | `url_from_offer_id` < 3535 | | **14.08 15:59** | `house_imv_backfill` | число застрявших убывает | | **16.08 13:37** | `avito_full_load_exhaustive` | `resume_from=3547`, `resume_buckets=35` | | **до 20.08** | проба Домклика (#2856) | бан пары `узел×domclick` с причиной `probe:browser` в сутки блокировки свипа. Если за неделю ни разу — правка бесполезна | | **04–09.09** | предупреждение о протухании Циана | сработает при непротухших данных | | **12.09** | координатный резолв квартала | не измерен ⇒ флаг и код удалить | --- # ОДНА ЖИВАЯ ПОЛОМКА, НАЙДЕННАЯ ПОБОЧНО — #2860 `yandex_newbuilding_sweep`: восемь прогонов подряд «обработано 5, успешно 0» со статусом **done** и пустым текстом ошибки. Очередь растёт 351 → 389, витрина стоит на 34 строках с 15.07. И последний прогон — 10.08, то есть он ещё и перестал быть суточным.
lekss361 added the
needs-discussion
needs-human
priority/p1
tradein
labels 2026-08-16 10:25:17 +00:00
Author
Collaborator

Ещё один пункт для этой сводки: ротация прокси не запускалась ни разу — не задан токен

Замер 20.08.2026. Всё, кроме одной переменной окружения, на месте.

Цепочка

1. rotate_url проставлен у ВСЕХ 4 узлов          (миграция 199 отработала)
2. ASOCKS_API_TOKEN в контейнере tradein-scraper  НЕ ЗАДАН
3. scrape_proxy_rotations                         0 строк, ни одной ротации
4. следствие — баны копятся, узлы выгорают

Функция #2611 написана, отревьюена, смержена, миграции применены — и не сработала ни разу. Это ровно тот класс, что описан в эпике #2674.

Что это стоит прямо сейчас

Пул — четыре узла. Забанено в эту минуту:

источник узлов всего забанено сейчас остаётся
domclick 4 3 1
avito 4 1 3
cian 4 0 4

asocks-residential-1 забанен для avito восьмой раз (ban_count=8, до 23.08).

Чем это оплачивается в сборе

domclick_city_sweep:      banned 11 подряд · последний done 05.08 — 15 суток назад
domclick_detail_backfill: banned 14        · последний done 05.08
avito_city_sweep:         banned 13        · последний done 17.08

Сторож просроченных источников (#2670) сообщает об этом верно и ежедневно: «6 источников не собирают дольше 3× своего такта».

Отдельно: по таблице listings Домклик выглядит свежим — последнее объявление 8 часов назад. Полного обхода при этом нет две недели. Свежесть таблицы маскирует отсутствие сбора, поэтому по ней судить нельзя.

Что при этом РАБОТАЕТ

Сдвиг стартовой корзины (#2854/#2932) выкатился и делает своё дело — 20.08 первый прогон со bucket_start_index=5 дал первое в истории источника buckets_completed=1 и 33 трёхкомнатных квартиры, которых не появлялось ни разу за две недели (10.08 было: 292 однушки, одна двушка, ноль трёшек). То есть слепая зона по комнатности снята — но объём остаётся ручейком, потому что узлы выгорают быстрее, чем восстанавливаются.

Что нужно от вас

Задать ASOCKS_API_TOKEN в окружении tradein-scraper. Сам токен не запрашиваю и в переписку не тяну — это ваша учётка; достаточно положить его туда же, где остальные секреты стека.

Проверить, что подействовало, можно одной строкой: SELECT count(*) FROM scrape_proxy_rotations — сейчас там ноль.

## Ещё один пункт для этой сводки: ротация прокси не запускалась ни разу — не задан токен Замер 20.08.2026. Всё, кроме одной переменной окружения, на месте. ### Цепочка ``` 1. rotate_url проставлен у ВСЕХ 4 узлов (миграция 199 отработала) 2. ASOCKS_API_TOKEN в контейнере tradein-scraper НЕ ЗАДАН 3. scrape_proxy_rotations 0 строк, ни одной ротации 4. следствие — баны копятся, узлы выгорают ``` Функция #2611 написана, отревьюена, смержена, миграции применены — и не сработала ни разу. Это ровно тот класс, что описан в эпике #2674. ### Что это стоит прямо сейчас Пул — четыре узла. Забанено **в эту минуту**: | источник | узлов всего | забанено сейчас | остаётся | |---|---|---|---| | domclick | 4 | **3** | 1 | | avito | 4 | 1 | 3 | | cian | 4 | 0 | 4 | `asocks-residential-1` забанен для avito **восьмой раз** (`ban_count=8`, до 23.08). ### Чем это оплачивается в сборе ``` domclick_city_sweep: banned 11 подряд · последний done 05.08 — 15 суток назад domclick_detail_backfill: banned 14 · последний done 05.08 avito_city_sweep: banned 13 · последний done 17.08 ``` Сторож просроченных источников (#2670) сообщает об этом верно и ежедневно: «6 источников не собирают дольше 3× своего такта». Отдельно: по таблице `listings` Домклик выглядит свежим — последнее объявление 8 часов назад. Полного обхода при этом нет две недели. Свежесть таблицы маскирует отсутствие сбора, поэтому по ней судить нельзя. ### Что при этом РАБОТАЕТ Сдвиг стартовой корзины (#2854/#2932) выкатился и делает своё дело — 20.08 первый прогон со `bucket_start_index=5` дал первое в истории источника `buckets_completed=1` и **33 трёхкомнатных** квартиры, которых не появлялось ни разу за две недели (10.08 было: 292 однушки, одна двушка, ноль трёшек). То есть слепая зона по комнатности снята — но объём остаётся ручейком, потому что узлы выгорают быстрее, чем восстанавливаются. ### Что нужно от вас Задать `ASOCKS_API_TOKEN` в окружении `tradein-scraper`. Сам токен не запрашиваю и в переписку не тяну — это ваша учётка; достаточно положить его туда же, где остальные секреты стека. Проверить, что подействовало, можно одной строкой: `SELECT count(*) FROM scrape_proxy_rotations` — сейчас там ноль.
Author
Collaborator

Замер источников на 20.08.2026

Снято с /api/v1/admin/scrape/freshness на проде. Общий статус — failed.

источник статус без успеха, сут последний успех последняя попытка
objective ok 0.9 19.08 21:30 19.08 21:30
gisogd_permits ok 9.6 11.08 03:34 11.08 03:34
nspd stale 24.7 27.07 01:06 17.08 01:02
nspd_geo stale 47.3 04.07 10:06 04.07 10:06
kn failed 53.1 28.06 16:00 28.06 14:57
kn_flats failed 53.1 28.06 16:00 28.06 14:57
cadastre failed 62.2 19.06 13:37 19.06 11:27

Живых источников два из семи. Отчёт сегодня опирается на Объектив (свежий) и ГИСОГД-разрешения (9.6 суток, в пределах порога); остальное — снимок двух-трёхмесячной давности.

Отдельно стоит строка nspd: последняя попытка 17.08, последний успех 27.07 — то есть загрузчик ходит и получает отказ уже 21 сутки подряд. Раньше эта разница была не видна: монитор считал успехом сам факт записи строки; починено ранее в этом эпике (success_where), и теперь nspd честно показывается как stale, а не ok.

Ни одной новой задачи не завожу — состояние покрыто #2443 (DOM.РФ WAF hard-ban), #2956 (НСПД с 27.07) и этой сводкой. Это обновление чисел, чтобы решение принималось по сегодняшнему состоянию, а не по июльскому.

## Замер источников на 20.08.2026 Снято с `/api/v1/admin/scrape/freshness` на проде. Общий статус — **failed**. | источник | статус | без успеха, сут | последний успех | последняя попытка | |---|---|---:|---|---| | objective | **ok** | 0.9 | 19.08 21:30 | 19.08 21:30 | | gisogd_permits | **ok** | 9.6 | 11.08 03:34 | 11.08 03:34 | | nspd | stale | 24.7 | 27.07 01:06 | **17.08 01:02** | | nspd_geo | stale | 47.3 | 04.07 10:06 | 04.07 10:06 | | kn | failed | 53.1 | 28.06 16:00 | 28.06 14:57 | | kn_flats | failed | 53.1 | 28.06 16:00 | 28.06 14:57 | | cadastre | failed | 62.2 | 19.06 13:37 | 19.06 11:27 | **Живых источников два из семи.** Отчёт сегодня опирается на Объектив (свежий) и ГИСОГД-разрешения (9.6 суток, в пределах порога); остальное — снимок двух-трёхмесячной давности. Отдельно стоит строка `nspd`: последняя **попытка** 17.08, последний **успех** 27.07 — то есть загрузчик ходит и получает отказ уже 21 сутки подряд. Раньше эта разница была не видна: монитор считал успехом сам факт записи строки; починено ранее в этом эпике (`success_where`), и теперь `nspd` честно показывается как stale, а не ok. Ни одной новой задачи не завожу — состояние покрыто #2443 (DOM.РФ WAF hard-ban), #2956 (НСПД с 27.07) и этой сводкой. Это обновление чисел, чтобы решение принималось по сегодняшнему состоянию, а не по июльскому.
Author
Collaborator

П.2 (получатель уведомлений в GlitchTip, #2673) — сделан

Владелец дописал TELEGRAM_ALERTS_CHAT_ID / TELEGRAM_ALERTS_TOPIC_ID в рантайм-конфиг; правила и получатели заведены раньше. Проверено доставкой, а не конфигом — подробности и три пробы (в том числе из самого glitchtip-worker по настоящему URL получателя) в #2673.

Ключевое, потому что переезд это едва не сломал: получатели прописаны публичным URL через Caddy, а не именем контейнера. GlitchTip остался на Beget, tradein-backend уехал на Poincare — по имени он оттуда не резолвится, и связность по общей докер-сети, описанная в докстринге модуля, больше не действует. Публичный URL это переживает; проба из glitchtip-worker вернула 200.

Оговорка из постановки («не делать правило „слать всё“ — 10 571 TimeoutError утопит остальное») учтена формой правил: окно 5 минут, порог 1, батч — GlitchTip шлёт одно сообщение на пачку неотправленных групп за такт, а не по событию.

Побочно вскрылось: секрет вебхука уезжает в Loki query-параметром, скруббер #3115 его не ловит. Вынес в #3154 — к вашему решению там только вопрос ротации, остальное чинится кодом.

Остальные пункты сводки без изменений.

## П.2 (получатель уведомлений в GlitchTip, #2673) — сделан Владелец дописал `TELEGRAM_ALERTS_CHAT_ID` / `TELEGRAM_ALERTS_TOPIC_ID` в рантайм-конфиг; правила и получатели заведены раньше. Проверено доставкой, а не конфигом — подробности и три пробы (в том числе из самого `glitchtip-worker` по настоящему URL получателя) в #2673. Ключевое, потому что переезд это едва не сломал: получатели прописаны **публичным URL через Caddy**, а не именем контейнера. GlitchTip остался на Beget, `tradein-backend` уехал на Poincare — по имени он оттуда не резолвится, и связность по общей докер-сети, описанная в докстринге модуля, больше не действует. Публичный URL это переживает; проба из `glitchtip-worker` вернула 200. Оговорка из постановки («не делать правило „слать всё“ — 10 571 `TimeoutError` утопит остальное») учтена формой правил: окно 5 минут, порог 1, батч — GlitchTip шлёт одно сообщение на пачку неотправленных групп за такт, а не по событию. Побочно вскрылось: секрет вебхука уезжает в Loki query-параметром, скруббер #3115 его не ловит. Вынес в #3154 — к вашему решению там только вопрос ротации, остальное чинится кодом. Остальные пункты сводки без изменений.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lekss361/gendesign#2704
No description provided.