wiki: ingest 2 concepts — sched-fnf-r8-verification-stand + windows-docker-test-harness-gotchas

2026-08-18 18:25:52 +03:00
parent fd2c1752f4
commit dbce833a98
4 changed files with 137 additions and 0 deletions
--- a/.wiki/concepts/sched-fnf-r8-verification-stand.md
+++ b/.wiki/concepts/sched-fnf-r8-verification-stand.md
@@ -0,0 +1,59 @@
+---
+title: "sched F&F r8 — стенд верификации (schedule-as-entity)"
+type: concept
+tags: [sched, fnf, verification, stand, verdaccio, schedule-as-entity, docker]
+sources: []
+related: [concepts/windows-docker-test-harness-gotchas.md]
+updated: 2026-08-18
+---
+
+# sched F&F r8 — стенд верификации
+
+Кросс-агентный цикл F&F (findings & fixes): sched-команда публикует пакеты в
+verdaccio, admin-сессия верифицирует на стенде и репортит находки через
+инбокс (`sched/.agents/inbox/`). Раунд r8 = «schedule-as-entity» (движок тикает
+по schedule-строкам). Цикл идёт письмами: intro → отчёт → фикс → перепроверка →
+следующий пункт.
+
+## Стенд
+
+- Путь: `C:\Users\vitya\projects\.admin\.tmp\sched-r8\` (gitignored, живёт на диске).
+- package.json: **@sched/core 0.40.1 / daemon 0.2.0 / storage-{mysql,postgres,mongo} 0.3.1** из verdaccio (`npm install --registry=https://verdaccio.kzntsv.site/`). `legacy/` — старый core 0.35.1 для генерации v0.6-БД.
+- Docker-контейнеры (как в CI sched): `sched-mysql-test` :3308, `sched-mariadb-test` :3307, `sched-postgres-test` :5433, `sched-mongo-test` :27017; root:test / postgres:test.
+
+## Репро-скрипты (15 шт., `.tmp/sched-r8/*.mjs`)
+
+**Миграции / адаптеры (№1):**
+- `migration-test.mjs` — sqlite v0.6→v0.7 (эталон синтеза)
+- `adapter-migration-test.mjs` — F2: mysql/pg v3→v5, синтез легаси-строки, due стреляет
+- `mongo-synthesis-test.mjs` — F2 mongo: first-open синтез, no-dup, non-empty gate. Легаси-док: коллекция `sched_tasks`, `config.data` (не `data`), `paused`/`disabled` обязательны (иначе null → не в due)
+- `priority-order-test.mjs` — F1: task priority 10 наследуется на строку
+- `adapters-spotcheck.mjs` — 12/12 CRUD+dedupKey-upsert на 4 адаптерах
+- `tasks-json-test.mjs` — модель tasks.json (schedules:[...], fail-fast legacy key)
+- `contract-parity.test.mjs` — vitest contract-сьют 5 адаптеров (см. гочу №2)
+
+**Движок (№2, 75 проверок):**
+- `engine-runs-test.mjs` (16) — scheduleId/data/trigger на schedule-ранах; manual (null+дефолты); retryRun (снапшот+retryOf)
+- `engine-due-claim-test.mjs` (10) — priority-порядок, ceiling с блокирующим раннером, pause, once, catch-up
+- `engine-retry-test.mjs` (27) — ретраи на строках (retryCount/backoff×multiplier/failCount/onRunFinal), override, retryOf-цепочка
+- `engine-watchdog-test.mjs` (14) — reap обоих наборов локов, heartbeat real-clock, recoverOrphanRuns
+- `engine-async-test.mjs` (8) — async poll через schedule-раны, poll timeout
+
+**Политики (№3, 21 проверка):**
+- `engine-policy-test.mjs` — whole-no-merge (override не наследует поля дефолта), snapshot-семантика пендинг-ретрая, pause AND два уровня, manual=дефолты задачи, priority-микс
+
+## Что подтверждено (контракт)
+
+- **Ceiling сериализует через тики**: две due-строки одной задачи стреляют в РАЗНЫХ тиках (sibling-claim отклоняется атомарно). Параллелизм только между задачами.
+- **onRunFinal** — на любом терминальном ране (успех тоже), не только на persistent-failure; «алерты только на фейлы» — фильтр consumer'а.
+- **retryCount на строке** = consumed-попытки (кумулятив: после 2 фейлов = 2).
+- **resolveSchedulePolicy** = `schedule.retry ?? task.retry` целиком; explicit `priority: 0` уважается как есть.
+- **Snapshot-семантика**: правка политики не пересчитывает дедлайн пендинг-ретрая; свежая политика — со следующего диспатча.
+- **pause AND**: `task.paused` гейтит все расписания (движок), `schedule.paused` — одно (due-запрос).
+- **manual triggerTask** = дефолты задачи (data, без schedule-политики), расписание не двигается.
+
+## Как продолжить (№4 API / №5 UI)
+
+1. Бамп версий в package.json стенда → `npm install --registry=...`.
+2. Новые проверки — отдельный `.mjs` по паттерну существующих (`check()` + SUMMARY), изолированные DB на сценарий.
+3. Отчёт — письмо в `sched/.agents/inbox/` с фронтматтером `from: admin`, формат «делал → ожидал → получил → раздел доки». Не чинить, не пушить, их доску не трогать.
--- a/.wiki/concepts/windows-docker-test-harness-gotchas.md
+++ b/.wiki/concepts/windows-docker-test-harness-gotchas.md
@@ -0,0 +1,75 @@
+---
+title: "Windows docker-тест-харнесс: грабли верификационных скриптов"
+type: concept
+tags: [windows, testing, node, docker, vitest, sqlite, gotchas]
+sources: []
+related: [concepts/sched-fnf-r8-verification-stand.md]
+updated: 2026-08-18
+---
+
+# Windows docker-тест-харнесс: грабли
+
+Собрано из верификационных прогонов против docker-контейнеров на Windows-хосте
+(стенд sched F&F r8, 2026-08-18). Переиспользуемо для любой проверки
+«локальные репро-скрипты против живых docker-БД».
+
+## 1. `rmSync` удаляемого sqlite-файла — EBUSY на Windows
+
+`new DatabaseSync('x.db')` создаёт файл, и `rmSync('x.db')` ПОСЛЕ открытия падает
+`EBUSY` (errno -4082): Windows не удаляет открытый файл (на POSIX unlink
+открытого — ок, на Windows — нет).
+
+**Правило: `rmSync` ДО `DatabaseSync`.** Порядок в тесте:
+```js
+rmSync('x.db', { force: true });
+const db = new DatabaseSync('x.db');
+```
+Симптом-ловушка: тот же EBUSY бывает, если файл держит ВИСЯЩИЙ node-процесс
+прошлого прогона (см. п.4) — сначала убить процессы, потом чинить порядок.
+
+## 2. vitest 10s-таймаут vs медленный docker-DDL
+
+На этом хосте DDL в docker-mysql8 стоит ~200–1500ms на запрос (CREATE TABLE,
+ALTER), а `createMysqlStorage` (миграции v1→v5 на свежей БД) — ~11s. vitest-дефолт
+10s на тест → каждый mysql-тест падает в `beforeEach` по таймауту, БЕЗ
+assertion-ошибок. Выглядит как регрессия, а это окружение.
+
+Варианты: `--testTimeout=60000`, либо (лучше для стенда) не гонять тяжёлый
+contract-сьют на mysql/pg/mariadb через vitest — покрывать те же пути
+отдельными node-скриптами (`adapters-spotcheck`, `adapter-migration-test`).
+
+## 3. Фейк-часы в тестах движка — монотонность и изоляция
+
+Инжектируемый `now()` даёт детерминизм, но:
+- **Часы должны идти МОНОТОННО.** Прыжок назад (например, после тика 10:03 гнать
+  once-расписание на 10:01) ломает: расписание «уже» выстрелило catch-up'ом на
+  более позднем тике, nextRunAt=null. Планируй все времена по возрастанию.
+- **Отдельный DB на сценарий.** Общий DB + прыгающие часы → соседняя задача
+  становится due на «чужом» тике и стреляет (мешает счётчикам/онRunFinal).
+- **`rmSync` в начале каждого прогона** — иначе повторный запуск видит старые
+  раны (флак «запусти ещё раз — упало»).
+- **Блокирующий раннер + `runOnce`** = дедлок, если release после `await`.
+  Тик не await'ить, дать микро-паузу на claim, release, потом `await`.
+
+## 4. Висельники node-процессов держат файлы/порты
+
+После таймаутов и убитых прогонов node-процессы живут и держат sqlite-файлы
+(→ EBUSY) и соединения. `tasklist | grep node` врёт (UTF-16 binary); правильно:
+```powershell
+Get-CimInstance Win32_Process -Filter "Name='node.exe'" | Select ProcessId,CommandLine
+```
+Убивать точечно по CommandLine (репо-путь), НЕ всех — рядом крутятся dev-серверы
+юзера (nuxt, pi-агенты, wiki-graph). Таймаут bash убивает шелл, но не дерево
+node-детей — чистить руками.
+
+## 5. Секвенции assert'ов: «ожидание» vs «поведение»
+
+Половина «багов» в репро-скриптах — неверные ожидания в тесте, а не движок:
+- кумулятивные счётчики (retryCount = consumed-попытки, не «текущая»);
+- тай-брейки сортировок (priority-равные → id ASC);
+- событийные хуки на терминальных ранах (success тоже);
+- легаси-форматы данных (mongo: `config.data` не `data`, `paused`/`disabled`
+  обязательны — иначе синтез даёт null и строка не в due).
+
+Перед репортом о «находке» — перепроверить, что ожидание соответствует доке
+(это часто и есть ответ: поведение документировано, тест был неверен).