(low) street-deals: period_from считается 30-дневными месяцами, а фильтр — календарными — отображаемое окно не совпадает с запросом #1381

New issue

Closed

opened 2026-06-14 18:10:06 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-14 18:10:06 +00:00

Collaborator

Описание

get_street_deals считает отображаемый period_from в Python как now - (period_months * 30) дней, а SQL WHERE фильтрует сделки по deal_date > NOW() - (period_months || ' months')::interval (календарные месяцы PostgreSQL). Для period_months=12 Python даёт ~360 дней, SQL — ~365 дней, поэтому period_from в ответе (показываемый пользователю как начало окна) на ~5 дней позже фактического cutoff, применённого к данным. Сами сделки выбираются корректно — расходится только отображаемая граница окна. Тот же паттерн проявится для любого period_months.

Корень

Две структурно несогласованные формулы для одного окна: фиксированные 30-дневные месяцы в Python против календарного interval в SQL.

Evidence

/Users/anton/Птица/gendesign/tradein-mvp/backend/app/api/v1/trade_in.py:1448, 1484

# 1448:
period_from: date = (now - timedelta(days=period_months * 30)).date()

-- 1484:
AND deal_date > NOW() - (CAST(:period_months AS integer) || ' months')::interval

Suggested fix

Согласовать отображаемый period_from с SQL-фильтром. Либо считать period_from через relativedelta(months=period_months) (календарные месяцы), либо менять SQL на фильтр по Python-вычисленной дате (bind :period_from, deal_date >= :period_from), чтобы заявленное и запрошенное окна совпадали.

Обоснование severity

Low: возвращаемые сделки корректны, искажена только отображаемая граница окна (~5 дней). Достижимо в проде (стандартный GET-route), но без потери/повреждения данных.

week ревью 1 · multi-agent аудит 2026-06-14 · severity=low · category=correctness

Затронутые файлы:

/Users/anton/Птица/gendesign/tradein-mvp/backend/app/api/v1/trade_in.py

## Описание `get_street_deals` считает отображаемый `period_from` в Python как `now - (period_months * 30)` дней, а SQL WHERE фильтрует сделки по `deal_date > NOW() - (period_months || ' months')::interval` (календарные месяцы PostgreSQL). Для `period_months=12` Python даёт ~360 дней, SQL — ~365 дней, поэтому `period_from` в ответе (показываемый пользователю как начало окна) на ~5 дней позже фактического cutoff, применённого к данным. Сами сделки выбираются корректно — расходится только отображаемая граница окна. Тот же паттерн проявится для любого `period_months`. ## Корень Две структурно несогласованные формулы для одного окна: фиксированные 30-дневные месяцы в Python против календарного `interval` в SQL. ## Evidence `/Users/anton/Птица/gendesign/tradein-mvp/backend/app/api/v1/trade_in.py:1448, 1484` ```python # 1448: period_from: date = (now - timedelta(days=period_months * 30)).date() ``` ```sql -- 1484: AND deal_date > NOW() - (CAST(:period_months AS integer) || ' months')::interval ``` ## Suggested fix Согласовать отображаемый `period_from` с SQL-фильтром. Либо считать `period_from` через `relativedelta(months=period_months)` (календарные месяцы), либо менять SQL на фильтр по Python-вычисленной дате (`bind :period_from`, `deal_date >= :period_from`), чтобы заявленное и запрошенное окна совпадали. ## Обоснование severity Low: возвращаемые сделки корректны, искажена только отображаемая граница окна (~5 дней). Достижимо в проде (стандартный GET-route), но без потери/повреждения данных. --- _week ревью 1 · multi-agent аудит 2026-06-14 · severity=**low** · category=`correctness`_ Затронутые файлы: - `/Users/anton/Птица/gendesign/tradein-mvp/backend/app/api/v1/trade_in.py`