Вернуть crash-safe запись AddBlock через tmp_bch

2026-06-26 17:05:37 +04:00
parent 1ced351ea2
commit 71fdee0cfd
10 changed files with 468 additions and 216 deletions
@@ -0,0 +1,47 @@
+# Crash-safe запись обычного `AddBlock` через `tmp_bch`
+
+## Кратко
+
+Обычный `AddBlock` переведён на схему:
+
+1. сборка `<blockchainName>.tmp_bch`;
+2. запись sidecar `<blockchainName>.write_check` с `blockNumber` и `blockHash`;
+3. создание пустого marker `<blockchainName>.write_pending`;
+4. SQL-транзакция;
+5. атомарная подмена `tmp -> main`;
+6. удаление временных файлов.
+
+## Что проверить
+
+1. Обычный `AddBlock` на свежей цепочке.
+2. Падение до SQL-commit:
+   - должны остаться только временные файлы;
+   - на старте они должны быть удалены.
+3. Падение после SQL-commit, но до `atomicReplaceBlockchainFile(...)`:
+   - на старте recovery должен довести swap до конца.
+4. Падение после `atomicReplaceBlockchainFile(...)`, но до удаления marker/sidecar:
+   - на старте recovery должен просто подчистить хвост.
+5. Сценарий без marker:
+   - `tmp_bch` / `write_check` считаются мусором и удаляются.
+
+## Ожидаемый результат
+
+- БД и файловая версия цепочки остаются согласованными.
+- Повторный старт сервера не ломает chain и не требует ручной правки файлов.
+- `BlockchainTmpRecoveryOnStartup` корректно обрабатывает и живые остатки, и мусор.
+
+## Статус
+
+`pending`
+
+## Что уже сделано
+
+- В коде есть `tmp_bch`, `write_check` и `write_pending`.
+- `BlockchainWriter` пишет обычный `AddBlock` через временные артефакты.
+- `BlockchainTmpRecoveryOnStartup` умеет добивать или чистить незавершённую запись.
+
+## Что ещё перепроверить
+
+- ручной crash-test на тестовом сервере;
+- совместимость с уже существующими `resync_pending` marker-файлами;
+- отсутствие ложных срабатываний на старых временных файлах.