Деградация каденции sync-vault вечером 2026-09-18

Связано: family/documents/vault-sync/2026-09-18-window-cap-silent-tick-undercount.md, family/documents/vault-sync/2026-09-14-cron-api-timeout-sync-outage.md

Что замечено

Начиная с ~15:00 UTC 2026-09-18 длительность LLM-раунда задачи sync-vault (job_id 29851c413903, prompt-задача bash /opt/data/sync-vault.sh) выросла с обычных 6–11 с до 150–1250 с. Сам скрипт при этом отрабатывает нормально — растёт именно ожидание ответа провайдера до вызова инструмента.

Замер по executions.db, окно 2026-09-17 22:00 → 2026-09-18 22:00 UTC:

час UTC	тиков	non-completed	суммарно агент-секунд
22–14	12/час	0	100–400
15:00	12	1 (`unknown`)	968
16:00	10	0	1227
17:00	8	1 (`failed`)	2799
18:00	6	0	1210
19:00	5	0	2359
20:00	12	0	686
21:00	9	1 (`running`)	1247

Длительности за сутки: n=265, медиана 10,9 с, p90 148 с, максимум 1254,8 с. Раундов >120 с — 30, все приходятся на 09:35 UTC и позже.

Пропущенные тики (17:00 — 8, 18:00 — 6, 19:00 — 5 вместо 12) — это не пропуск диспетчера: claim предыдущего запуска держится, пока висит LLM-раунд, поэтому слоты 5-минутной сетки выпадают (механика описана в заметке 2026-09-14).

Ошибки за сутки

2026-09-18T15:55:45 — unknown, «Scheduler restarted after this execution's owner exited before a durable terminal state» (раунд 512,9 с). Лог /tmp/vault-sync.log при этом не обнулялся (первая строка по-прежнему 2026-09-15 11:35:19) — перезапуска контейнера не было, перезапустился владелец исполнения.
2026-09-18T17:55:33 — failed, RuntimeError: Request timed out. (1254,8 с = 20,9 мин).
2026-09-18T21:55:59 — running (этот самый тик; скрипт вызван в 22:00:43, то есть собственный раунд тоже занял ~4,7 мин).

Состояние данных (проверено 2026-09-18 22:01 UTC)

Ручной прогон cd /opt/data && bash /opt/data/sync-vault.sh → exit 0, Pushed ✓ по всем трём фазам (syncthing / taiga-vault / syncthing-out).

bare /vault.git = /vault = /obsidian-syncthing = 49776108afb3a683149ebcabf1f61ab951926bfc
git status --porcelain пуст в обоих клонах
молчащих тиков в окне лога 09-15 11:35:19 → 09-18 22:00:43: 20 из 965 (2,1 %) (метод с капом окна по следующему тику)
максимальный разрыв в логе за вечер — 17,3 мин (21:43:24 → 22:00:43), порог 30 мин не превышен

Потерь данных нет: git-синк идемпотентен, все три репозитория на одном коммите, рабочие каталоги чистые. Вечерняя деградация — потеря каденции (~50 % запусков в 17:00–19:00), а не потеря содержимого.

Обновление 2026-09-18 22:12 UTC

Продолжение эпизода, прерывистое (чередование нормы и длинных раундов):

тик UTC	длительность раунда
21:40:58	591 с
21:56:00	326 с
22:05:00	7 с (норма)
22:10:01	>140 с (активный на момент записи)

Пропущены слоты 21:45 / 21:50 / 21:55 и 22:00 — claim долгих раундов держал 5-минутную сетку. Скрипт на 22:10-тике вызван в 22:12:23: все три фазы Pushed ✓, изменений нет.

Состояние данных (2026-09-18 22:12 UTC): /vault.git = /vault = /obsidian-syncthing = 5e2ffd5, git status --porcelain пуст в обоих клонах.

Что делать

Вмешательство в конфиг пока не требуется (единичный эпизод деградации провайдера, восстанавливается сам). Если эпизоды повторятся — вариант, требующий решения владельца: убрать LLM из петли (hermes cron edit 29851c413903 --no-agent --script <path>, путь должен быть персистентным — /root/.hermes в контейнере не переживает рекреацию) или пин модели/провайдера для этой задачи.

5.0 KiB Raw Blame History Unescape Escape