6 commits

Author	SHA1	Message	Date
bot-backend	c7df2732bd	fix(ops): алерт не теряется от одного сетевого отказа (#3059) ... Путь Selectel-Telegram теряет соединения. Замер 26.08 с Poincare, 40 подключений к закреплённому (#3093) 149.154.167.220: успешно 37 из 40, отказов 3 (7.5%) - все TimeoutError время успешных: min 0.14s, медиана 0.15s, max 0.17s Отказы происходят на стадии ПОДКЛЮЧЕНИЯ - быстрые стабильные успехи на фоне редких таймаутов. Три остальных дата-центра Telegram с Selectel недостижимы вовсе, так что закрепление адреса потери убрать не может: запасного адреса нет. Бот это переживает своими ретраями (106 таймаутов за сутки, 97 лечатся первой же повторной попыткой), а вот алерты - нет. uptime-healthcheck.sh: был один curl и `|| log WARN` - каждый отказ терял уведомление целиком. Сторож, который не может дозваться, - худший вид самоскрывающейся поломки: чем хуже дела на проде, тем выше шанс, что о них не сообщат. Ирония в том, что ниже в этом же файле HTTP-проверки уже повторяются циклом: ретраили то, что измеряют, но не то, чем докладывают. lib-backup.sh: тоже один curl, но с падением в почту (#3070). Алерт не терялся, зато каждый транзиентный таймаут впустую сжигал последнее средство вместо простого переподключения. Стало: цикл из трёх попыток в обеих notify(). Не `curl --retry` - семантика --max-time при ретраях зависит от версии curl, а цикл даёт таймаут на КАЖДУЮ попытку и повторяет идиому, уже принятую в uptime-healthcheck.sh. Дубль вместо потери - осознанный размен: sendMessage не идемпотентен, но отказ случается ДО отправки запроса, так что повтор почти никогда не продублирует доставленное. Лишний алерт безвреден, пропущенный - нет. Тесты (backend/tests/ops/test_3059_alert_retry.py, 7 шт) исполняют РЕАЛЬНЫЕ notify(), извлечённые из обоих скриптов, с подставным curl, отказывающим заданное число раз, и считают фактическое число попыток. Фальсификация: на исходных скриптах краснеют 6 из 7. Проходит только test_backup_falls_back_to_mail_when_telegram_is_really_down - он фиксирует сохранённое поведение, а не регресс. Проверено: `bash -n` обоих скриптов (та же проверка, что в CI - shellcheck там нет); конструкция `[[ ]] && cmd` в конце тела цикла безопасна под `set -euo pipefail`, который стоит в uptime-healthcheck.sh:25 (проверено исполнением, не рассуждением); tests/ops целиком - 22 passed.	2026-08-26 10:02:46 +03:00
bot-backend	cdf493f345	chore(format): нормализация под ruff 0.15.20 — 161 файл, только формат (#2864) (#3022)	2026-08-21 12:01:52 +00:00
bot-backend	70f3c0a88a	fix(ops): проверка трейлера дампа падала на grep — ведущие -- принимались за опции (#2203) ... verify_dump_integrity() в ops/backup.sh и tradein-mvp/deploy/backup-tradein-db.sh делала `grep -qF "$trailer"`, где $trailer = "-- PostgreSQL database dump complete". Ведущие -- в аргументе grep трактует как конец опций/флаг, без разделителя команда падает: `grep: unrecognized option '-- PostgreSQL...'`. Проверка из-за этого ВСЕГДА возвращала "трейлера нет" — не потому что дамп оборван, а потому что сама проверка не могла выполниться. Вызывающий код удалял только что созданный валидный дамп и завершался с ошибкой; ретеншен не успевал отработать (ранний exit) — свежие бэкапы не создавались никогда, старые копии оставались молча. Воспроизведено вручную на проде: bash /opt/gendesign/tradein-mvp/deploy/backup-tradein-db.sh удалил свежий дамп с сообщением "дамп оборван?". Фикс: `grep -qF -- "$trailer"` — `--` явно завершает список опций grep. Регрессионный тест (backend/tests/ops/test_2203_backup_trailer_grep_dashdash.py) исполняет РЕАЛЬНУЮ verify_dump_integrity() из обоих скриптов на настоящем gzip-потоке через gunzip|tail|grep — не читает исходник текстом. Проверено локально: падает на добаговой версии с тем же "unrecognized option", зелен на исправленной.	2026-08-20 23:38:45 +03:00
bot-backend	68d041022d	fix(ci): ожидание докер-лока оставляет след в логе (#2950) (#2958)	2026-08-20 08:44:10 +00:00
bot-backend	feff8214f7	fix(ci): докер-секции прод-деплоев исключают друг друга через host-lock (#2950) (#2955)	2026-08-20 08:13:56 +00:00
bot-backend	2a01dea103	fix(ci): прод-деплои в одну группу concurrency — прун одного убивал pull другого (#2950) (#2952)	2026-08-20 07:47:48 +00:00