(medium) search.py/search(): cache_hit всегда false даже при отдаче из кэша — поле врёт #1515

New issue

Closed

opened 2026-06-15 05:59:04 +00:00 by bot-backend · 1 comment

bot-backend commented

2026-06-15 05:59:04 +00:00

Collaborator

Severity: medium · Категория: report · Файл: tradein-mvp/backend/app/api/v1/search.py:34-59

search.py:50-57 — response собирается с явным cache_hit=False (строка 56), затем сериализуется в кэш (строка 59: cache.set(..., response.model_dump(...))). На последующем HIT строка 40 возвращает SearchResponse.model_validate(cached) как есть, не переопределяя флаг. Импакт: поле cache_hit в ответе API на практике никогда не равно true — ломает мониторинг/отладку эффективности кэша и вводит клиента в заблуждение. Чинить: в ветке HIT (строки 35-40) выставлять флаг перед возвратом, напр. resp = SearchResponse.model_validate(cached); resp.cache_hit = True; return resp — и/или не персистить cache_hit в кэше. Тест test_search_cache_hit маскирует баг, подсовывая cached_payload с cache_hit=True вручную.

Почему баг: Объект response строится с явным cache_hit=False (search.py:56) ДО записи в кэш (search.py:59), и именно это значение персистится. Ветка HIT (search.py:35-40) не переопределяет флаг. Тест test_search_cache_hit (test_search_api.py:106-119) маскирует баг: он вручную подсовывает cached_payload с cache_hit=True, чего реальный код set() никогда не делает. Поле для мониторинга/отладки эффективности кэша всегда показывает промах.

Как чинить: В ветке HIT проставлять флаг: resp = SearchResponse.model_validate(cached); resp.cache_hit = True; return resp. Либо не сериализовать cache_hit в кэш, а выставлять его на чтении.

_{deep-audit «армия ботов 2» · verify+harden, confidence 0.9 · unit U120}

**Severity:** medium · **Категория:** report · **Файл:** `tradein-mvp/backend/app/api/v1/search.py:34-59` search.py:50-57 — response собирается с явным cache_hit=False (строка 56), затем сериализуется в кэш (строка 59: cache.set(..., response.model_dump(...))). На последующем HIT строка 40 возвращает SearchResponse.model_validate(cached) как есть, не переопределяя флаг. Импакт: поле cache_hit в ответе API на практике никогда не равно true — ломает мониторинг/отладку эффективности кэша и вводит клиента в заблуждение. Чинить: в ветке HIT (строки 35-40) выставлять флаг перед возвратом, напр. resp = SearchResponse.model_validate(cached); resp.cache_hit = True; return resp — и/или не персистить cache_hit в кэше. Тест test_search_cache_hit маскирует баг, подсовывая cached_payload с cache_hit=True вручную. **Почему баг:** Объект response строится с явным cache_hit=False (search.py:56) ДО записи в кэш (search.py:59), и именно это значение персистится. Ветка HIT (search.py:35-40) не переопределяет флаг. Тест test_search_cache_hit (test_search_api.py:106-119) маскирует баг: он вручную подсовывает cached_payload с cache_hit=True, чего реальный код set() никогда не делает. Поле для мониторинга/отладки эффективности кэша всегда показывает промах. **Как чинить:** В ветке HIT проставлять флаг: `resp = SearchResponse.model_validate(cached); resp.cache_hit = True; return resp`. Либо не сериализовать cache_hit в кэш, а выставлять его на чтении. --- <sub>deep-audit «армия ботов 2» · verify+harden, confidence 0.9 · unit U120</sub>

bot-backend added the

week ревью 1

label 2026-06-15 05:59:04 +00:00

bot-backend added the

scope/backend

label 2026-06-15 11:02:16 +00:00

lekss361 commented

2026-06-15 11:15:24 +00:00

Owner

🔍 week ревью 1 — верификация (ПОДТВЕРЖДЕНО)

Текущее состояние кода: tradein-mvp/backend/app/api/v1/search.py:34-64

Корень: объект response собирается с cache_hit=False (search.py:56) и именно это значение персистится в кэш на MISS (search.py:59 — cache.set(..., response.model_dump(...))). Ветка HIT (search.py:34-40) возвращает SearchResponse.model_validate(cached) без переопределения флага. → поле cache_hit в реальном ответе никогда не True, что ломает мониторинг эффективности кэша. Тест tradein-mvp/backend/tests/test_search_api.py:106-120 (test_search_cache_hit) маскирует баг — вручную подсовывает cached_payload с "cache_hit": True, чего код set() никогда не пишет.

Что править:

В ветке HIT (search.py:35-40) выставлять флаг перед возвратом:
```
resp = SearchResponse.model_validate(cached)
resp.cache_hit = True
return resp
```
И/или не сериализовать cache_hit в кэш (исключить из dump), выставляя его только на чтении — устранит «отравление» значения.

Что посмотреть:

Код: search.py:34-64; search_response.py:53 (cache_hit: bool = False в SearchResponse). Тест test_search_api.py:106-120 переписать так, чтобы кэш-payload приходил из реального response.model_dump() (MISS) и затем проверялся HIT с cache_hit is True — тогда тест перестанет маскировать баг.
Vault: релевантных заметок не найдено.

**🔍 week ревью 1 — верификация (ПОДТВЕРЖДЕНО)** **Текущее состояние кода:** `tradein-mvp/backend/app/api/v1/search.py:34-64` **Корень:** объект `response` собирается с `cache_hit=False` (`search.py:56`) и именно это значение персистится в кэш на MISS (`search.py:59` — `cache.set(..., response.model_dump(...))`). Ветка HIT (`search.py:34-40`) возвращает `SearchResponse.model_validate(cached)` без переопределения флага. → поле `cache_hit` в реальном ответе никогда не `True`, что ломает мониторинг эффективности кэша. Тест `tradein-mvp/backend/tests/test_search_api.py:106-120` (`test_search_cache_hit`) маскирует баг — вручную подсовывает `cached_payload` с `"cache_hit": True`, чего код `set()` никогда не пишет. **Что править:** - В ветке HIT (`search.py:35-40`) выставлять флаг перед возвратом: ```python resp = SearchResponse.model_validate(cached) resp.cache_hit = True return resp ``` - И/или не сериализовать `cache_hit` в кэш (исключить из dump), выставляя его только на чтении — устранит «отравление» значения. **Что посмотреть:** - Код: `search.py:34-64`; `search_response.py:53` (`cache_hit: bool = False` в `SearchResponse`). Тест `test_search_api.py:106-120` переписать так, чтобы кэш-payload приходил из реального `response.model_dump()` (MISS) и затем проверялся HIT с `cache_hit is True` — тогда тест перестанет маскировать баг. - Vault: релевантных заметок не найдено.