3.1 KiB
08 — Требования к данным / схеме БД (ORCH-021)
Вывод: миграция БД НЕ требуется
Состояние наблюдения хранится в sentinel-файлах (restart-safe, без миграции — по образцу ORCH-36/53/58), а не в таблицах. Реестры и схема не меняются (AC-12).
1. Существующие таблицы — без изменений
events,tasks,agent_runs,jobs— структура не меняется.- В
tasksНЕ вводится колонка статуса/окна наблюдения (намеренно — миграция на проде = риск, как обосновано в adr-0007; альтернатива отклонена в ADR-001 §Альтернативы).
2. Очередь jobs — переиспользование, без схемы
post-deploy-monitor— новый job-kind (значение в существующей колонкеagent/task_content), НЕ новая колонка. Ставится через существующийenqueue_job(..., available_at_delay_s=...)(ORCH-1).- Счётчик тиков/деферов восстанавливается из jobs-очереди (как
_deploy_finalize_defer_countсчитает поtask_content LIKE), restart-safe.
3. Sentinel-состояние (файлы, не БД)
State-dir .post-deploy-state-<repo>/<work_item_id>/ на settings.repos_dir
(по образцу .deploy-state-*):
| Файл | Назначение |
|---|---|
armed |
наблюдение заармлено (идемпотентность арма; калька INITIATED) |
series |
JSON-список результатов опросов (счётчики health-fail / 5xx; restart-safe) |
done |
наблюдение завершено (защита от повторной обработки) |
Все обращения — never-raise (по образцу self_deploy.has_marker/write_marker/
read_result). Отсутствие/битость файла → консервативный фоллбэк, не исключение.
4. Артефакт 16-post-deploy-log.md — файл репозитория, не БД
Машиночитаемый YAML-frontmatter (post_deploy_status, action_taken, window_s,
checks_total, checks_failed) пишется best-effort в docs/work-items/<id>/; в БД
не реплицируется. Источник для петли уроков ORCH-8 (BR-10).
5. Очистка состояния
По завершении окна / реакции done-маркер ставится; state-dir можно чистить
best-effort (по образцу self_deploy.clear_state) — необязательно для корректности,
но желательно для гигиены. Stale-armed без done после краха → виден в /queue
как «активное наблюдение» и доигрывается восстановленным job'ом.