Files
healthlog/docs/backlog/reindex-iz-arhiva.md
T
av 91e860cfc8 docs: ссылки на план по названиям шагов вместо номеров
- шесть ссылок уже указывали не туда: самоописание значилось шагом 5 (оно 6), import — шагом 6 (он 8), TLS — шагом 8 (это деплой, 11)
- README, local-research.md и беклог переведены на названия; нумерация остаётся внутренним делом plan.md
2026-08-02 06:54:08 +03:00

2.3 KiB

Пересборка хранилища из сырого архива

Приоритет: высокий

Разбор пишется по реальным данным и будет ошибаться — это норма, а не риск. Риск в другом: без пересборки ошибка разбора становится потерей данных — исправленный код не применится к тому, что уже разобрано неверно.

Пересчёт по всей истории сразу ещё и точнее приёма: вывод слоя и род агрегации на полном ряду доставок надёжнее, чем на одной.

Проектировать это надо сразу как свёртку по журналу, а не как разовую утилиту: состояние есть import(снапшот экспорта) + replay(доставки после его даты), и пересборка из архива — вырожденный случай с пустым снапшотом. Тогда reindex и import окажутся одной операцией с разным входом, а не двумя похожими.

Отсюда требование, которое легко упустить: свёртка обязана быть детерминированной. Проигрывание должно давать то же состояние, что приём в реальном времени. Слияние «выигрывает более полная точка» коммутативно, но две одинаково полные точки с разными значениями разрешает порядок — значит воспроизведение идёт строго по received_at, а не по порядку файлов в каталоге.

Готово, когда пересборка с нуля даёт состояние, совпадающее с накопленным приёмом, и повторный прогон ничего не меняет.

Связано: план → шаг «Разбор и хранилище», docs/architecture.md → «Сырой архив».