Files
obsidian-vault/family/documents/vault-sync/2026-09-18-window-cap-silent-tick-undercount.md
T

5.4 KiB
Raw Blame History

Окно сверки лога: кап по следующему тику (2026-09-18)

Связано: family/documents/vault-sync/2026-09-16-silent-tick-clusters.md

Суть

Метод сверки executions.db с /tmp/vault-sync.log по окну [claimed_at 45 с; finished_at + 90 с] занижает число молчащих тиков, если тик был затянувшимся: его окно заходит в интервал следующего тика и захватывает его строку [syncthing] Pushed ✓.

Наблюдение: тик 2026-09-18T09:35:51finished_at 09:39:41 (230,8 с — LLM-раунд растянулся, вероятно деградация провайдера). Строк в логе за этот тик нет вообще. Окно без капа: [09:35:06; 09:41:11] — а строка следующего тика 09:40:55 попадает внутрь, поэтому тик считался «не молчащим».

Исправленный метод

Верхняя граница = min(finished_at + 90 с, claimed_at следующего тика).

for i,(cl,fin,st,err) in enumerate(sel):
    if st!='completed' or not fin: continue
    a,b=P(cl),P(fin)
    nxt=P(sel[i+1][0]) if i+1<len(sel) else None
    hi=b+timedelta(seconds=90)
    if nxt: hi=min(hi, nxt)
    if not any(a-timedelta(seconds=45)<=t<=hi for t in logts):
        silent.append((cl[:16],round((b-a).total_seconds(),1)))

Замер (окно лога 2026-09-15 11:35:19 → 2026-09-18 11:35:16, 853 строки)

  • тиков: 863, молчащих: 15 (1,7 %), failed: 1 (старый Fire claim lost, 2026-09-15 11:30)
  • без капа по следующему тику выходило 14 (1,6 %) — расхождение ровно на затянувшемся тике 09:35
  • длительности: медиана 10,1 с, p95 20,9 с, максимум 230,8 с (тот самый тик)

Состояние на момент проверки (2026-09-18 11:35 UTC)

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

  • bare /vault.git = /vault = /obsidian-syncthing = 54d69ca885d42249b9d4a1af6bd697d30c9b51ad
  • git status --porcelain пуст в обоих клонах
  • ошибок в логе (No such file or directory, error, fatal) — 0

Вывод: молчащие тики — известный и безвредный режим (git-синк идемпотентен, следующий тик догоняет всё); методика сверки обновлена, вмешательство в конфиг не требуется.

Добавлено 17:15 UTC — деградация провайдера во второй половине дня (затянувшиеся LLM-раунды)

Плановый прогон 17:14:47 UTC → exit 0, Pushed ✓ по всем трём фазам, SHA выровнены: bare /vault.git = /vault = /obsidian-syncthing = 774f53135293ff5e81d9b44ce67f7fec49d7ab78, git status --porcelain пуст.

Но каденция сегодня просела. Статистика executions.db за 2026-09-18 (203 тика, медиана длительности 10,7 с):

тик (UTC) длительность, с
00:00 85,4
09:35 230,8
11:35 63,9
14:35 161,8
14:40 144,9
15:00 161,0
15:20 146,0
15:55 512,9 → статус unknown
16:04 157,0
16:25 147,0
16:40 433,5
16:55 436,5
17:05 598,0 (подтверждено 17:20 — ровно на пороге таймаута 600 с)

Итого 12 тиков >60 с, из них 8 — после 14:35. Разрывы в /tmp/vault-sync.log: 15:55:48→16:06:52 (11,1 мин), 16:30:25→16:47:27 (17,0 мин), 16:55:29→17:14:47 (19,3 мин).

Механика: пока затянувшийся запуск держит claim, очередной 5-минутный тик не стартует вовсе — тик 17:00 в executions.db отсутствует (предыдущий, 16:55, завершился только в 17:02:42), поэтому это пропуск планировщика, а не молчащий LLM-тик из методики выше.

Отдельная аномалия: тик 15:55:45finished_at 16:04:18, status=unknown, error='Scheduler restarted after this execution's owner exited before a durable terminal state; whether side effects ran is unknown.' — перезапуск планировщика Hermes около 16:04; в логе за этот интервал строки есть (16:06:52, следующий тик), потери данных нет.

Состояние данных: потерь нет, git-синк идемпотентен, все три клона на одном коммите. Вмешательство в конфиг не требуется (см. правило 2026-09-14: править конфиг только при повторяющихся эпизодах). Если серия затянутых тиков (150–500 с) продолжится >суток — рассмотреть hermes cron edit 29851c413903 --no-agent --script или пин модели/провайдера.