From 87eec7e5c9adae7e4da7a9d6d61019877c83d00fede7f880328929b79a14cffd Mon Sep 17 00:00:00 2001 From: AidarKC Date: Fri, 26 Jun 2026 17:46:34 +0400 Subject: [PATCH] =?UTF-8?q?=D0=97=D0=B0=D1=84=D0=B8=D0=BA=D1=81=D0=B8?= =?UTF-8?q?=D1=80=D0=BE=D0=B2=D0=B0=D1=82=D1=8C=20=D1=83=D1=81=D0=BF=D0=B5?= =?UTF-8?q?=D1=88=D0=BD=D1=83=D1=8E=20=D1=81=D0=B8=D0=BD=D1=85=D1=80=D0=BE?= =?UTF-8?q?=D0=BD=D0=B8=D0=B7=D0=B0=D1=86=D0=B8=D1=8E=20=D0=BD=D0=B0=20?= =?UTF-8?q?=D1=82=D0=B5=D1=81=D1=82=D0=BE=D0=B2=D0=BE=D0=BC=20=D1=81=D0=B5?= =?UTF-8?q?=D1=80=D0=B2=D0=B5=D1=80=D0=B5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Dev_Docs/Blockchain/CHANGELOG.md | 8 +++++ Dev_Docs/Blockchain/sync-between-servers.md | 13 ++++++++ ..._sync_servers_bootstrap_from_server_pda.md | 13 -------- ...ddblock_background_sync_to_sync_servers.md | 15 ---------- ...026-06-25_1200_periodic_blockchain_sync.md | 30 ------------------- ...6-26_1100_blockchain_resync_cleanup_dao.md | 19 ------------ ...1330_blockchain_resync_startup_recovery.md | 17 ----------- ...6-26_1745_proverka_avariynykh_ostanovok.md | 29 ++++++++++++++++++ VERSION.properties | 4 +-- 9 files changed, 52 insertions(+), 96 deletions(-) delete mode 100644 Dev_Docs/Pending_Features/2026-06-24_1905_sync_servers_bootstrap_from_server_pda.md delete mode 100644 Dev_Docs/Pending_Features/2026-06-24_1945_addblock_background_sync_to_sync_servers.md delete mode 100644 Dev_Docs/Pending_Features/2026-06-25_1200_periodic_blockchain_sync.md delete mode 100644 Dev_Docs/Pending_Features/2026-06-26_1100_blockchain_resync_cleanup_dao.md delete mode 100644 Dev_Docs/Pending_Features/2026-06-26_1330_blockchain_resync_startup_recovery.md create mode 100644 Dev_Docs/Pending_Features/2026-06-26_1745_proverka_avariynykh_ostanovok.md diff --git a/Dev_Docs/Blockchain/CHANGELOG.md b/Dev_Docs/Blockchain/CHANGELOG.md index 37c4383..ad73912 100644 --- a/Dev_Docs/Blockchain/CHANGELOG.md +++ b/Dev_Docs/Blockchain/CHANGELOG.md @@ -1,5 +1,13 @@ # История изменений документации блокчейна +# 2026-06-26 17:45:18 +0400 +- Базовый коммит-ориентир: `44a1ba0`. +- На `t.shineup.me` подтверждена рабочая схема startup sync и full-resync: + - после рестарта сервер добивает `BlockchainTmpRecovery` и `BlockchainResyncRecovery`; + - `aidartest-001` успешно подтягивается с `shineup.me`; + - итоговое локальное состояние по `aidartest-001` дошло до `last_block_number=13`. +- В `Dev_Docs/Blockchain/sync-between-servers.md` добавлен практический результат ручной проверки на тестовом сервере. + ## 2026-06-26 17:03:22 +0400 - Базовый коммит-ориентир: `71fdee0`. - Обычный `AddBlock` переведён на crash-safe схему через временный кандидат `.tmp_bch`, sidecar `.write_check` и marker `.write_pending`. diff --git a/Dev_Docs/Blockchain/sync-between-servers.md b/Dev_Docs/Blockchain/sync-between-servers.md index 63a9378..c8a4fc5 100644 --- a/Dev_Docs/Blockchain/sync-between-servers.md +++ b/Dev_Docs/Blockchain/sync-between-servers.md @@ -241,3 +241,16 @@ Full resync запускается только тогда, когда: Следующие отдельные шаги после текущего этапа: - отдельно проверить full-resync и startup-recovery на реальном тестовом прогоне после ручного удаления БД/файлов. + +### 8.1 Практическая проверка на тестовом сервере + +Проверка на `t.shineup.me` показала, что текущая схема действительно поднимает цепочку при старте: + +- после рестарта сервер сначала проходит `BlockchainTmpRecovery`; +- затем обрабатывает `BlockchainResyncRecovery`; +- после этого сам догружает цепочку `aidartest-001` с `shineup.me`; +- итоговое состояние на тестовом сервере: + - `blockchain_state.last_block_number = 13` + - `blocks` по `aidartest-001` = `14` записей + +Это подтверждает, что startup sync и full-resync flow работают в живом сценарии, а не только в коде. diff --git a/Dev_Docs/Pending_Features/2026-06-24_1905_sync_servers_bootstrap_from_server_pda.md b/Dev_Docs/Pending_Features/2026-06-24_1905_sync_servers_bootstrap_from_server_pda.md deleted file mode 100644 index c570d50..0000000 --- a/Dev_Docs/Pending_Features/2026-06-24_1905_sync_servers_bootstrap_from_server_pda.md +++ /dev/null @@ -1,13 +0,0 @@ -# Стартовая загрузка `sync_servers` из server PDA - -- Краткое описание: - - При запуске сервер читает свой логин из `server.SHiNE.login`, загружает свою server PDA из Solana, достаёт `sync_servers`, затем читает PDA партнёров и сохраняет их `login + server_address + updated_at_ms` в локальную таблицу `sync_servers`. -- Что проверять: - - В `application.properties` задан `server.SHiNE.login=shineupme`. - - После старта сервера в SQLite появилась/обновилась таблица `sync_servers`. - - В таблице лежат логины и адреса серверов из `sync_servers` текущего server PDA. - - При изменении `sync_servers` или `server_address` в Solana и перезапуске сервера локальная таблица обновляется. -- Ожидаемый результат: - - Сервер без ручного ввода адресов подтягивает партнёров синхронизации из Solana PDA и хранит их локально для следующих этапов репликации. -- Статус: - - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-24_1945_addblock_background_sync_to_sync_servers.md b/Dev_Docs/Pending_Features/2026-06-24_1945_addblock_background_sync_to_sync_servers.md deleted file mode 100644 index 71dc748..0000000 --- a/Dev_Docs/Pending_Features/2026-06-24_1945_addblock_background_sync_to_sync_servers.md +++ /dev/null @@ -1,15 +0,0 @@ -# Фоновая one-shot синхронизация `AddBlock` на `sync_servers` - -- Краткое описание: - - После успешного локального `AddBlock` сервер в фоне пытается отправить тот же блок всем партнёрам из локальной таблицы `sync_servers`. - - Если партнёр отвечает `bad_prev_hash` или `bad_block_number`, сервер один раз делает backfill: читает недостающие блоки из БД по диапазону и досылает их по одному. - - Если в процессе возникает новая ошибка, попытка для этого партнёра прерывается без повторов. -- Что проверять: - - При добавлении нового блока клиент получает быстрый `OK`, не ожидая завершения межсерверной рассылки. - - В логах видно попытки отправки на адреса из `sync_servers`. - - При отставании партнёра сервер досылает пропущенный хвост блоков по одному. - - При ошибке после backfill сервер не зацикливается и не блокирует основной `AddBlock`. -- Ожидаемый результат: - - Репликация `AddBlock` работает в фоне и не ломает основной путь записи блока. -- Статус: - - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-25_1200_periodic_blockchain_sync.md b/Dev_Docs/Pending_Features/2026-06-25_1200_periodic_blockchain_sync.md deleted file mode 100644 index c9d647a..0000000 --- a/Dev_Docs/Pending_Features/2026-06-25_1200_periodic_blockchain_sync.md +++ /dev/null @@ -1,30 +0,0 @@ -# Периодическая межсерверная синхронизация блокчейнов - -- Краткое описание: - - При старте сервер подтягивает `sync_servers` из server PDA и сохраняет адреса партнёров в локальную таблицу. - - После успешного локального `AddBlock` работает фоновая one-shot отправка нового блока партнёрам. - - Добавлен публичный `GetBlockchainBlock` для чтения одного блока. - - Добавлен публичный `GetSyncUserProfile` для подготовки отсутствующей локальной цепочки без прямого Solana RPC. - - Добавлен плановый sync блокчейнов при старте сервера и затем каждые `12` часов. - - Синхронизация пока умеет только докачивать отсутствующий хвост цепочки. - - Добавлена настройка `sync.importUserProfileFromPartner.enabled`, которая включает создание локального `solana_users + blockchain_state` по ответу сервера-партнёра вместо Solana PDA. - - Случай рассинхрона цепочек пока не исправляется автоматически: он только логируется как не реализованный сценарий. - -- Что именно проверять: - - После старта сервера в логах появляется запуск периодического sync. - - Сервер может запросить у партнёра `ListBlockchainHeads`. - - Сервер может запросить у партнёра `GetSyncUserProfile`, если включён `sync.importUserProfileFromPartner.enabled=true`. - - Сервер может запросить у партнёра `GetBlockchainBlock` и локально применить блок через существующий `AddBlock`. - - На чистом тестовом сервере после удаления БД и файлов блокчейнов сервер сам подтягивает блоки при старте. - - При включённом режиме обхода Solana сервер восстанавливает локальные цепочки без запросов в Solana RPC. - - После первичного старта новые блоки продолжают догоняться без ручного вмешательства. - - При рассинхроне цепочек в логах появляется явное сообщение, что reconciliation пока не реализован. - -- Ожидаемый результат: - - Чистый сервер после старта сам восстанавливает локальные цепочки от партнёра синхронизации. - - В режиме обхода Solana чистый сервер не упирается в `Solana RPC 429` при создании локальных chain-state для уже существующих на партнёре пользователей. - - Периодический sync не мешает обычной работе сервера и не ломает локальный `AddBlock`. - - Нереализованный случай рассинхрона не приводит к падению сервера и явно отражается в логах. - -- Статус: - - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-26_1100_blockchain_resync_cleanup_dao.md b/Dev_Docs/Pending_Features/2026-06-26_1100_blockchain_resync_cleanup_dao.md deleted file mode 100644 index 133ecf1..0000000 --- a/Dev_Docs/Pending_Features/2026-06-26_1100_blockchain_resync_cleanup_dao.md +++ /dev/null @@ -1,19 +0,0 @@ -# DAO очистки одной blockchain-цепочки перед полным resync - -- Краткое описание: - - Добавлен отдельный DAO-метод, который в одной SQL-транзакции очищает одну blockchain-цепочку перед её полной повторной загрузкой. - - Внутри транзакции сначала уменьшаются чужие `likes_count` и `replies_count`, которые были увеличены блоками удаляемой цепочки. - - Затем удаляются локальные записи цепочки и её derived-state. - - Файлы `.bch` / `.tmp_bch` этот DAO не удаляет: файловый шаг будет отдельной следующей задачей. - - DAO уже используется в periodic full-resync flow, но это ещё не было вручную проверено на прод-цикле. - -- Что именно проверять: - - Метод корректно компилируется и не ломает сборку. - - Метод подключён в рабочий periodic full-resync path, но manual e2e verification ещё нужна. - - Комментарии в коде понятны и соответствуют реальному порядку SQL-шагов. - -- Ожидаемый результат: - - Появилась изолированная транзакционная точка очистки одной цепочки, на которую можно безопасно опереться при следующем шаге реализации divergence-resync. - -- Статус: - - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-26_1330_blockchain_resync_startup_recovery.md b/Dev_Docs/Pending_Features/2026-06-26_1330_blockchain_resync_startup_recovery.md deleted file mode 100644 index 4e9c032..0000000 --- a/Dev_Docs/Pending_Features/2026-06-26_1330_blockchain_resync_startup_recovery.md +++ /dev/null @@ -1,17 +0,0 @@ -# Startup recovery для marker-file resync цепочек - -- Краткое описание: - - При старте сервер сканирует `data/*.resync_pending` и добивает незавершённые full-resync цепочки перед тем, как перейти к обычной работе. - - Пока marker-file не убран, обычный `AddBlock` в эту цепочку возвращает `chain_resync_in_progress`. - -- Что именно проверять: - - Сервер не начинает обычный `periodic sync`, пока не отработают все marker-file recovery. - - Если marker-файлы есть, startup-blocking реально останавливает нормальный старт до их обработки. - - Если восстановление одной цепочки падает, marker остаётся на диске и сервер не переходит в обычный режим. - - После успешного восстановления marker удаляется. - -- Ожидаемый результат: - - После внезапной перезагрузки сервер не продолжает обычную работу с поломанной цепочкой, а сначала добивает незавершённый resync. - -- Статус: - - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-26_1745_proverka_avariynykh_ostanovok.md b/Dev_Docs/Pending_Features/2026-06-26_1745_proverka_avariynykh_ostanovok.md new file mode 100644 index 0000000..d6dbab0 --- /dev/null +++ b/Dev_Docs/Pending_Features/2026-06-26_1745_proverka_avariynykh_ostanovok.md @@ -0,0 +1,29 @@ +# Проверка аварийных остановок на разных этапах + +## Кратко + +Нужно отдельно проверить, как сервер восстанавливается после внезапной остановки: + +1. во время обычного `AddBlock` / `tmp_bch`-pipeline; +2. во время `full resync` цепочки; +3. во время startup recovery, если остановка произошла на предыдущем запуске; +4. при обычном апгрейде сервиса без явного crash-сценария. + +## Что проверять + +1. Остановка сервиса до `commit` БД. +2. Остановка сервиса после `commit`, но до замены `main.bch`. +3. Остановка сервиса во время `BlockchainResyncCleanupDAO`. +4. Остановка сервиса во время повторной загрузки цепочки по `GetBlockchainBlock`. +5. Поведение при обычном `systemctl restart`, когда сервер сам должен добить recovery. + +## Ожидаемый результат + +- после старта сервер либо дочищает временные артефакты, либо завершает незаконченный `resync`; +- не остаётся битых `.tmp_bch`, `.write_check`, `.write_pending`, `.resync_pending`; +- БД и файлы цепочки остаются согласованными; +- обычная работа сервера не стартует поверх незавершённого recovery. + +## Статус + +`pending` diff --git a/VERSION.properties b/VERSION.properties index 8135c2b..015d4a4 100644 --- a/VERSION.properties +++ b/VERSION.properties @@ -1,2 +1,2 @@ -client.version=1.2.278 -server.version=1.2.258 +client.version=1.2.279 +server.version=1.2.259