Files
ros_control/docs/changes/007-fast-offline-detection/summary.md
T

19 lines
2.6 KiB
Markdown
Raw Normal View History

# Итоги: 007 — быстрое обнаружение недоступности
## Сделано
- Таймаут соединения 4 с отдельно от таймаута чтения 30 с (`RosClient`, `ROS_CONNECT_TIMEOUT`).
- Фоновый опрос (`app/services/poller.py`, запускается в `lifespan`): период `POLL_INTERVAL=30` с, лёгкий и полный режимы
(`ops.poll_device`); сбой одного устройства не останавливает остальных, при остановке приложения задача корректно отменяется.
- Автообновление страницы «Устройства» каждые 15 с без перезагрузки и без потери выбора/открытых меню (`static/app.js`, `HX-Push-Url` при автообновлении не отправляется).
- Новые настройки в `.env.example`: `ROS_CONNECT_TIMEOUT`, `POLL_INTERVAL`, `UPDATE_CHECK_INTERVAL` (значения по умолчанию заданы в коде — существующий `.env` менять не нужно).
## Проверено
- `pytest`: 9 из 9 (добавлен тест опроса: недоступно → возврат с полным опросом → лёгкий опрос обновляет uptime, остальные поля сохраняются; в тестах опрос выключен).
- Вживую: статусы обновляются каждые 30 с без обращений пользователя; адрес без ответа определяется за 4,0 с (было до 30 с);
новое недоступное устройство помечается offline за ≤24 с без ручного опроса; в браузере страница сама показала «1 offline» через 15 с,
история не засорена, ошибок JS нет. Тестовые устройства удалены.
## Ограничения
- Худшее время обнаружения: `POLL_INTERVAL` + `ROS_CONNECT_TIMEOUT` (≈34 с) плюс до 15 с до обновления страницы.
- Во время перезагрузки устройства (обновление ROS/FW) оно кратковременно отображается как offline — это ожидаемо.
- Интервал 30 с при большом парке даёт по одному лёгкому запросу на устройство в 30 с; нагрузку ограничивает `MAX_CONCURRENCY`.