Вернуть 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
@@ -30,7 +30,6 @@

 - `near/2026-05-25_1106_telegram_agent_players.md` - разрешённые пользователи Telegram для агента, отдельные папки игроков, персональные истории и публикация краткого вопроса/ответа в общий канал.
 - `near/2026-05-25_1106_wallet_topup_solana_arweave.md` - пополнение Solana и Arweave через внешний сервис покупки с подсказкой и копированием адреса.
- `near/2026-06-26_1215_tmp_bch_для_обычного_addblock.md` - вернуть обычному `AddBlock` настоящую crash-safe схему через `.tmp_bch` и привести writer к модели startup-recovery.

 ### Среднесрочные

@@ -1,45 +0,0 @@
-# Вернуть настоящую tmp_bch-схему для обычного AddBlock
-
-## Зачем нужна эта доработка
-
-Сейчас обычный `AddBlock` пишет данные так:
-
-1. в SQL-транзакции добавляет блок в БД и обновляет `blockchain_state`;
-2. делает `commit`;
-3. только после этого дописывает основной файл `<blockchainName>.bch`.
-
-Это рабочая схема, но она не идеально crash-safe. Если сервер резко упадёт между `commit` БД и записью файла, можно получить состояние:
-
- в БД новый блок уже есть;
- в `.bch` файла этого блока ещё нет.
-
-При этом в проекте уже есть логика startup-recovery через `*.tmp_bch`, но текущий `BlockchainWriter` её полноценно не использует. Из-за этого writer и recovery сейчас живут в разных моделях.
-
-## Что планируем сделать
-
-Нужно вернуть единую и понятную схему:
-
-1. обычный `AddBlock` работает через временный файл `<blockchainName>.tmp_bch`;
-2. после успешной подготовки нового содержимого выполняется атомарная подмена `tmp -> main`;
-3. `BlockchainTmpRecoveryOnStartup` и `BlockchainWriter` используют одну и ту же модель;
-4. при резкой перезагрузке сервер на старте может корректно добрать или откатить незавершённый файловый шаг.
-
-## Что уже есть в коде
-
- recovery-класс: `SHiNE-server/src/main/java/server/ws/BlockchainTmpRecoveryOnStartup.java`
- файловые helper-методы под `tmp_bch`: `SHiNE-server/shine-server-blockchain/src/main/java/utils/files/FileStoreUtil.java`
- текущий writer: `SHiNE-server/shine-server-net-protocol/src/main/java/server/logic/ws_protocol/JSON/handlers/blockchain/Net_AddBlock_Handler_utils/BlockchainWriter.java`
-
-## Что надо будет изменить
-
-1. Переписать `BlockchainWriter`, чтобы он больше не писал сразу в основной `.bch`.
-2. Привести порядок записи и замены файла в соответствие с `BlockchainTmpRecoveryOnStartup`.
-3. Проверить сценарии:
-   - обычный `AddBlock`;
-   - резкий restart до commit БД;
-   - резкий restart после commit БД, но до замены файла;
-   - recovery на старте при наличии `*.tmp_bch`.
-
-## Почему это отложено отдельно
-
-Это отдельная задача от server-to-server resync. Для divergence-resync сейчас важнее сначала закончить безопасный SQL cleanup одной цепочки, а усиление crash-safety обычного `AddBlock` делать следующим самостоятельным шагом.