8e0479c616
All checks were successful
CI Trade-In / changes (pull_request) Successful in 16s
CI / changes (pull_request) Successful in 16s
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / backend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Has been skipped
CI Trade-In / backend-tests (pull_request) Successful in 5m11s
CI / frontend-tests (pull_request) Has been skipped
Однопоточный long-polling воркер обрабатывал апдейты строго последовательно, и ничто не мешало одному флудящему клиенту слать поток сообщений: каждое зеркалировалось (copyMessage) в support-топик, а групповой Telegram-лимит ~20 msg/min общий на ВСЕХ клиентов сразу — превышение даёт 429 с ожиданием 30-60с, за которое воркер не может обработать ни одного апдейта от кого-либо ещё. Переиспользован app.core.ratelimit.SlidingWindowLimiter (тот же примитив, что уже применён для веб-чата поддержки, app/api/v1/support.py) — ключ здесь TELEGRAM chat_id отправителя, лимит заметно ниже группового Telegram-порога (5 msg/60s). Сообщения сверх бюджета не зеркалируются (и не пишутся в tg_support_messages — маршрутизировать ответ всё равно нечего без topic_message_id), клиент получает явное уведомление о недоставке РОВНО один раз за окно (второй лимитер с limit=1 на то же окно) — молчать нельзя (клиент решит, что доставлено), но повторные уведомления на каждое превышение сами стали бы источником флуда. |
||
|---|---|---|
| .. | ||
| api | ||
| core | ||
| observability | ||
| schemas | ||
| services | ||
| tasks | ||
| __init__.py | ||
| main.py | ||
| scheduler_main.py | ||
| tgbot_main.py | ||