tradein/dadata: услуга CLEAN (стандартизация) выключена на аккаунте — HTTP 403, /estimate работает через suggest-fallback без canonical/cadnum (решение владельца: включить… #3401

New issue

Open

opened 2026-09-06 07:18:32 +00:00 by bot-backend · 1 comment

bot-backend commented

2026-09-06 07:18:32 +00:00

Collaborator

Факт (прод, 06.09, лог backend при /estimate):

WARNING app.services.dadata: dadata: HTTP 403 — услуга CLEAN (Стандартизация) выключена на аккаунте …
INFO    app.services.dadata: dadata: CLEAN недоступен → suggest-fallback '<адрес>' → house_fias_id=<uuid> (canonical/cadnum недоступны без CLEAN)

Код честно деградирует (app/services/dadata.py:~486): адрес резолвится через suggest (house_fias_id есть), но канонический адрес и кадастровый номер квартиры/дома из CLEAN не приходят — это влияет на канонизацию адреса (tradein_canon_addr, #2189) и на всё, что ключуется по cadnum.

Это не дефект кода — аккаунт DaData: услуга «Стандартизация» (CLEAN) платная и на аккаунте выключена (ключи DADATA_API_TOKEN/SECRET в backend заданы). Решение владельца: (а) включить/оплатить CLEAN на dadata.ru — тогда fallback перестанет срабатывать сам; (б) принять деградацию — тогда снять WARNING на каждый вызов (шум) и зафиксировать в документации оценщика, что canonical/cadnum не заполняются.

Проверка после решения: docker logs tradein-backend | grep 'CLEAN недоступен' → 0 за сутки при (а); при (б) — строка уходит на DEBUG.

Refs #2189 (канонизация адреса), #3059 (интеграции после переезда — не ломается ли DaData по IP: 403 с текстом про услугу, не про IP).

**Факт (прод, 06.09, лог backend при `/estimate`):** ``` WARNING app.services.dadata: dadata: HTTP 403 — услуга CLEAN (Стандартизация) выключена на аккаунте … INFO app.services.dadata: dadata: CLEAN недоступен → suggest-fallback '<адрес>' → house_fias_id=<uuid> (canonical/cadnum недоступны без CLEAN) ``` Код честно деградирует (`app/services/dadata.py:~486`): адрес резолвится через `suggest` (house_fias_id есть), но канонический адрес и кадастровый номер квартиры/дома из CLEAN не приходят — это влияет на канонизацию адреса (`tradein_canon_addr`, #2189) и на всё, что ключуется по cadnum. **Это не дефект кода — аккаунт DaData:** услуга «Стандартизация» (CLEAN) платная и на аккаунте выключена (ключи `DADATA_API_TOKEN/SECRET` в backend заданы). Решение владельца: (а) включить/оплатить CLEAN на dadata.ru — тогда fallback перестанет срабатывать сам; (б) принять деградацию — тогда снять WARNING на каждый вызов (шум) и зафиксировать в документации оценщика, что canonical/cadnum не заполняются. **Проверка после решения:** `docker logs tradein-backend | grep 'CLEAN недоступен'` → 0 за сутки при (а); при (б) — строка уходит на DEBUG. Refs #2189 (канонизация адреса), #3059 (интеграции после переезда — не ломается ли DaData по IP: 403 с текстом про услугу, не про IP).

bot-backend commented

2026-09-11 18:56:50 +00:00

Author

Collaborator

Замер срочности (11.09), чтобы приоритет был честным.

Частота сейчас нулевая: за сутки в логах tradein-backend ноль обращений к app.services.dadata и ноль строк «CLEAN недоступен» — просто потому, что оценок 1-7 в день (предзапусковый период, часть из них — мои пробы). То есть сегодня услуга не болит; заболит ровно когда пойдёт поток клиентов B2C.
Теряется меньше, чем выглядит. Fallback (app/services/dadata.py:486-494) отдаёт house_fias_id (house-level ФИАС, qc_geo=0), а без CLEAN пропадают canonical_address и house_cadnum. Но кадастр от DaData и так был пуст: в коде оценщика это зафиксировано замером — estimator.py:1491 и :3511: «dadata.house_cadnum пуст в 15 из 15 прод-применений квартального индекса», и там же сделан обход (квартал снимается другим путём, estimator.py:4676-4682). Значит фактическая потеря от выключенного CLEAN — нормализованный canonical_address, а не кадастровая привязка.

Что нужно от владельца: CLEAN — платная услуга в личном кабинете DaData; включать её или нет, решение денежное. Предлагаю: не включать сейчас, вернуться к вопросу перед открытием потока клиентов, и до тех пор держать issue открытым как предзапусковый чек-лист. Если решишь включать — скажи, я проверю эффект по значению (доля адресов с canonical_address, изменение попаданий в дом при подборе аналогов) и закрою.

Отдельно: fallback-путь работает и логирует себя честно — тихой деградации здесь нет.

**Замер срочности (11.09), чтобы приоритет был честным.** 1. **Частота сейчас нулевая:** за сутки в логах `tradein-backend` ноль обращений к `app.services.dadata` и ноль строк «CLEAN недоступен» — просто потому, что оценок 1-7 в день (предзапусковый период, часть из них — мои пробы). То есть сегодня услуга не болит; заболит ровно когда пойдёт поток клиентов B2C. 2. **Теряется меньше, чем выглядит.** Fallback (`app/services/dadata.py:486-494`) отдаёт `house_fias_id` (house-level ФИАС, `qc_geo=0`), а без CLEAN пропадают `canonical_address` и `house_cadnum`. Но кадастр от DaData **и так был пуст**: в коде оценщика это зафиксировано замером — `estimator.py:1491` и `:3511`: «dadata.house_cadnum пуст в 15 из 15 прод-применений квартального индекса», и там же сделан обход (квартал снимается другим путём, `estimator.py:4676-4682`). Значит фактическая потеря от выключенного CLEAN — нормализованный `canonical_address`, а не кадастровая привязка. **Что нужно от владельца:** CLEAN — платная услуга в личном кабинете DaData; включать её или нет, решение денежное. Предлагаю: не включать сейчас, вернуться к вопросу перед открытием потока клиентов, и до тех пор держать issue открытым как предзапусковый чек-лист. Если решишь включать — скажи, я проверю эффект по значению (доля адресов с `canonical_address`, изменение попаданий в дом при подборе аналогов) и закрою. Отдельно: fallback-путь работает и логирует себя честно — тихой деградации здесь нет.