bot-backend
015b310f62
All checks were successful
CI Trade-In / changes (pull_request) Successful in 9s
CI Trade-In / backend-tests (pull_request) Has been skipped
CI Trade-In / browser-tests (pull_request) Has been skipped
CI / changes (pull_request) Successful in 11s
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / frontend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Successful in 2m0s
CI / backend-tests (pull_request) Successful in 16m20s
Разбирая неоднозначные ядра, find_geo_matches геокодил ВСЕХ objective-кандидатов, включая тех, чьё имя уже занято в objective_complex_mapping. Записать такое имя нельзя в принципе: apply_geo_matches вставляет с ON CONFLICT (objective_complex_name, objective_group) DO NOTHING, а _TAKEN_NAMES_SQL выбирает ровно по этому ключу. Последствия на боевом пути: - занятый кандидат мог оказаться единственным в радиусе и уходил в confirmed — прогон рапортовал подтверждение, за которым запись молча не делала ничего; - занятый рядом со свободным давал «двое в радиусе» → ambiguous_multi, хотя выбор был единственным; - квота DaData (лимит 200 вызовов за прогон) тратилась на заведомо непишущихся. Замер на проде 19.08: 930 несопоставленных domrf ЕКБ-объектов, из них 14 неоднозначных; 28 слотов кандидатов, 14 занятых; 3 из 6 разных адресов к геокоду принадлежали занятым. После отсева у всех 14 остаётся ровно один кандидат. Заодно причина отказа перестаёт врать: при пустом in_radius это 'too_far', а не 'ambiguous_multi'; когда заняты все кандидаты — отдельная 'all_candidates_taken'. После отсева случай «остался один кандидат» становится частым, и старая метка читалась бы оператором как факт неоднозначности. |
||
|---|---|---|
| .. | ||
| api | ||
| core | ||
| models | ||
| observability | ||
| resources/certs | ||
| schemas | ||
| scrapers | ||
| services | ||
| templates | ||
| workers | ||
| __init__.py | ||
| main.py | ||