Аудит §2 переписан под решения (var-гейт, LF, дедуп закрыт — дублей нет); backlog: TD-COMMENTS-IFACE п.1–3 закрыты, TD-STYLE-ANALYZERS закрыт; STATUS.md — новый блок захода, устаревший блок «Осталось (в backlog)» в шапке удалён; план и ledger захода.
5.4 KiB
5.4 KiB
Task 2 — Отчёт: BanGuard (квоты, паузы, flood)
Статус: DONE
Что сделано по шагам
Step 1: Модуль backend/app/services/ban_guard.py (создан)
Реализован по интерфейс-спеке брифа (в брифе «дословного» кода нет — только сигнатуры и поведение, см. Concerns #1):
joins_today_auto() -> int—count(*)изdisc_logпоevent='join_auto'сcreated_at >= начало текущих UTC-суток(datetime.now(timezone.utc) .replace(hour=0,minute=0,second=0,microsecond=0)→ ms).can_auto_join() -> bool—joins_today_auto() < discJoinLimitИnot flood_today()Иnot global_paused().async wait_join_delay() -> None—asyncio.sleep(random.uniform(discJoinDelayMin, discJoinDelayMax))(значения изstore.get_setting).note_flood() -> None—store.set_setting("discFloodDay", <start_of_day_ms>).flood_today() -> bool—discFloodDay == start_of_day_ms(вчерашний флуд-день автоматически «протухает» в полночь UTC).global_paused() -> bool/set_global_pause(v: bool) -> None— settingdiscPaused.search_pause() -> float—random.uniform(2.0, 4.0).
Детали реализации:
- Хелпер
_start_of_day_ms()общий для квоты, флуда и паузы. - Ключи настроек вынесены в модульные константы (
_KEY_*) — в коде нет «голых» строк. discPaused/discFloodDayне вDEFAULT_SETTINGS(рантайм-настройки):get_settingвозвращаетNone, который трактуется как «не взведено» (False/0).- Стиль модуля — как в соседних сервисах:
from ..db import store, русские докстринги,from __future__ import annotations.
Step 2: Проверка на временной БД в контейнере
Первая попытка упала: ImportError: cannot import name 'ban_guard' — код копируется в
образ при сборке (backend/Dockerfile: COPY backend/app ./app), исходники не
монтируются, а образ был собран до создания файла. Выполнена пересборка
docker compose build app (2.6s, слой кода — единственный не из кэша), затем команда
из брифа прошла (вывод ниже).
Изменённые файлы
backend/app/services/ban_guard.py(создан)
Вывод проверок
1. py_compile
$ cd /c/telbase && python -m py_compile backend/app/services/ban_guard.py
COMPILE_OK # без ошибок
2. Временная БД в контейнере (команда из брифа Step 2)
$ docker compose build app # необходимо, т.к. код запекается в образ
$ docker compose run --rm --no-deps -e PYTHONPATH=/srv -e LEADRADAR_DATA=/tmp/lr_bg --entrypoint python app -c "
from app.db import store; store.init()
from app.services import ban_guard as bg
assert bg.can_auto_join() is True
assert bg.joins_today_auto() == 0
bg.note_flood(); assert bg.flood_today() is True
bg.set_global_pause(True); assert bg.can_auto_join() is False
print('BANGUARD OK')
"
BANGUARD OK
Все 4 assert'а из брифа прошли. ✔
Дополнительно
- Статическая проверка (diagnostics Zed): ошибок и предупреждений нет.
Concerns
- «Весь код — в брифе» — фактически неверно: в
task-2-brief.md(и в плане) нет ни одного блока кода модуля, только интерфейс-спека (~10 сигнатур с описанием поведения) и команда проверки. «Транскрибировать дословно» было нечего; модуль реализован по спеке. Очевидных ошибок/противоречий в спеке не нашёл — править было нечего. Если планировался эталонный код — его нужно добавить в бриф. wait_join_delay()иsearch_pause()не покрыты проверкой Step 2 (оба — случайные паузы; дефолт паузы вступления 50–70 сек, поэтому в проверку они не входили). Логика тривиальная (random.uniform+asyncio.sleep), но «живого» прогона нет.can_auto_join()приdiscJoinLimit <= 0всегдаFalse(осторожная сторона: лимит 0 = «не вступать»).- Клампы пауз (5..600) независимы —
min > maxтеоретически возможно через UI (унаследованный concern из Task 1; вwait_join_delayтогда диапазон «вывернется», но не упадёт). Перекрёстную проверку бриф не требовал. - Для проверок последующих задач нужна пересборка образа после каждого изменения backend-кода (образ не монтирует исходники).