Добавить TODO с планами на будущее
This commit is contained in:
AidarKC
parent
87eec7e5c9
commit
0cdcc77606
40
TODO/2026-06-26_1800_graceful_shutdown_30s.md
Normal file
40
TODO/2026-06-26_1800_graceful_shutdown_30s.md
Normal file
@ -0,0 +1,40 @@
|
|||||||
|
# Graceful shutdown на 30 секунд
|
||||||
|
|
||||||
|
## Зачем
|
||||||
|
|
||||||
|
Чтобы при `restart` или `stop` сервер получал небольшой запас времени на завершение опасных операций:
|
||||||
|
|
||||||
|
- текущий `AddBlock`;
|
||||||
|
- full resync цепочки;
|
||||||
|
- очистку marker-file;
|
||||||
|
- дописывание временных файлов.
|
||||||
|
|
||||||
|
Это должно уменьшить число случаев, когда приходится потом добирать хвост recovery-логикой.
|
||||||
|
|
||||||
|
## Что сделать
|
||||||
|
|
||||||
|
1. На стороне `systemd` задать `TimeoutStopSec=30s`.
|
||||||
|
2. В коде добавить корректную обработку shutdown-сигнала:
|
||||||
|
- перестать принимать новые блоки и sync-задачи;
|
||||||
|
- дождаться текущих операций;
|
||||||
|
- выйти в пределах таймаута.
|
||||||
|
3. При необходимости закрывать текущие ресурсы аккуратно:
|
||||||
|
- сетевые соединения;
|
||||||
|
- фоновые executor-ы;
|
||||||
|
- временные marker-файлы.
|
||||||
|
|
||||||
|
## Что уже есть
|
||||||
|
|
||||||
|
- `BlockchainTmpRecoveryOnStartup` и `BlockchainResyncRecoveryOnStartup` уже умеют добирать незавершённые хвосты после старта.
|
||||||
|
- `AddBlock` уже стал crash-safe через `tmp_bch` / `write_check` / `write_pending`.
|
||||||
|
|
||||||
|
## Откуда продолжать
|
||||||
|
|
||||||
|
- начать с `systemd`-юнита и базового shutdown-hook в сервере;
|
||||||
|
- затем проверить, что текущие операции реально завершаются в отведённые 30 секунд.
|
||||||
|
|
||||||
|
## Какие документы потом обновить
|
||||||
|
|
||||||
|
- `Dev_Docs/deploy/`;
|
||||||
|
- `Dev_Docs/Blockchain/sync-between-servers.md`, если изменится поведение остановки/восстановления.
|
||||||
|
|
||||||
41
TODO/2026-06-26_1805_server_to_server_ws_and_dm_sync.md
Normal file
41
TODO/2026-06-26_1805_server_to_server_ws_and_dm_sync.md
Normal file
@ -0,0 +1,41 @@
|
|||||||
|
# Постоянный server-to-server WS и DM sync
|
||||||
|
|
||||||
|
## Зачем
|
||||||
|
|
||||||
|
Сейчас синхронизация между серверами работает в основном как periodic sync и one-shot push. Для нормальной репликации ещё нужен постоянный межсерверный канал:
|
||||||
|
|
||||||
|
- живое подключение к партнёру;
|
||||||
|
- push новых блоков;
|
||||||
|
- push DM;
|
||||||
|
- ACK на доставку;
|
||||||
|
- backoff/reconnect;
|
||||||
|
- стартовый backfill.
|
||||||
|
|
||||||
|
## Что сделать
|
||||||
|
|
||||||
|
1. Поднять постоянное WebSocket-соединение между партнёрскими серверами.
|
||||||
|
2. Сделать push новых блоков сразу после `AddBlock`.
|
||||||
|
3. Сделать push DM-блоков между серверами.
|
||||||
|
4. Добавить ACK и повторную отправку при сбое.
|
||||||
|
5. Ввести стартовый обмен курсорами и добор хвоста.
|
||||||
|
|
||||||
|
## Что уже есть
|
||||||
|
|
||||||
|
- `ListBlockchainHeads`;
|
||||||
|
- `GetBlockchainBlock`;
|
||||||
|
- `GetSyncUserProfile`;
|
||||||
|
- базовый periodic sync;
|
||||||
|
- базовый backfill хвоста;
|
||||||
|
- базовый full resync при divergence.
|
||||||
|
|
||||||
|
## Откуда продолжать
|
||||||
|
|
||||||
|
- от текущего `sync_servers` bootstrap и `PeriodicBlockchainSyncService`;
|
||||||
|
- дальше выделить отдельный межсерверный transport layer.
|
||||||
|
|
||||||
|
## Какие документы потом обновить
|
||||||
|
|
||||||
|
- `Dev_Docs/Blockchain/sync-between-servers.md`;
|
||||||
|
- `Dev_Docs/Personal_Messages/README.md`;
|
||||||
|
- `Dev_Docs/API/`.
|
||||||
|
|
||||||
30
TODO/2026-06-26_1810_qr_device_sessions.md
Normal file
30
TODO/2026-06-26_1810_qr_device_sessions.md
Normal file
@ -0,0 +1,30 @@
|
|||||||
|
# Подключение других устройств по QR и типизированные сессии
|
||||||
|
|
||||||
|
## Зачем
|
||||||
|
|
||||||
|
QR-подключение других устройств сейчас есть как заготовка, но сценарий нужно довести до устойчивого состояния. Параллельно надо аккуратно оформить типизированные сессии homeserver-ов в PDA.
|
||||||
|
|
||||||
|
## Что сделать
|
||||||
|
|
||||||
|
1. Довести QR-сценарий до стабильного подключения нового устройства.
|
||||||
|
2. Нормально описать и хранить устройство как отдельную типизированную сессию.
|
||||||
|
3. Согласовать это с серверной и UI-логикой.
|
||||||
|
4. Проверить, что подключение работает одинаково на новом и повторном устройстве.
|
||||||
|
|
||||||
|
## Что уже есть
|
||||||
|
|
||||||
|
- в планах есть `сессионные homeserver-ы в PDA`;
|
||||||
|
- в планах есть `подключение других устройств через QR`;
|
||||||
|
- базовая заготовка уже существует, но сценарий считается нестабильным.
|
||||||
|
|
||||||
|
## Откуда продолжать
|
||||||
|
|
||||||
|
- от текущих документов в `Dev_Docs/Future_Features/medium/`;
|
||||||
|
- отдельно проверить, какие поля уже есть в PDA и UI.
|
||||||
|
|
||||||
|
## Какие документы потом обновить
|
||||||
|
|
||||||
|
- `Dev_Docs/Solana_Architecture/README.md`;
|
||||||
|
- `Dev_Docs/Future_Features/medium/2026-06-03_подключение_других_устройств_через_qr.md`;
|
||||||
|
- `Dev_Docs/Future_Features/medium/2026-06-02_сессионные_homeserver_в_pda.md`.
|
||||||
|
|
||||||
29
TODO/2026-06-26_1815_esp32_file_storage.md
Normal file
29
TODO/2026-06-26_1815_esp32_file_storage.md
Normal file
@ -0,0 +1,29 @@
|
|||||||
|
# ESP32 как личное файловое хранилище
|
||||||
|
|
||||||
|
## Зачем
|
||||||
|
|
||||||
|
Планируется использовать ESP32 как личное файловое хранилище SHiNE для переписок и вложений.
|
||||||
|
|
||||||
|
## Что сделать
|
||||||
|
|
||||||
|
1. Продумать формат хранения файлов на устройстве.
|
||||||
|
2. Согласовать загрузку и чтение файлов между UI, сервером и устройством.
|
||||||
|
3. Проверить, как устройство показывает статусы и ошибки.
|
||||||
|
4. Свести это с существующим homeserver/UI-прототипом.
|
||||||
|
|
||||||
|
## Что уже есть
|
||||||
|
|
||||||
|
- в списке будущих фич уже есть отдельная задача по ESP32S3 file storage;
|
||||||
|
- для UI homeserver уже есть отдельная документация и скетч должны держаться синхронно.
|
||||||
|
|
||||||
|
## Откуда продолжать
|
||||||
|
|
||||||
|
- от `Dev_Docs/Future_Features/medium/2026-05-26_0029_esp32s3_file_storage.md`;
|
||||||
|
- от документации по ESP32 UI homeserver.
|
||||||
|
|
||||||
|
## Какие документы потом обновить
|
||||||
|
|
||||||
|
- `Dev_Docs/Future_Features/medium/2026-05-26_0029_esp32s3_file_storage.md`;
|
||||||
|
- `Dev_Docs/Future_Features/README.md`;
|
||||||
|
- документацию по ESP32 UI homeserver, если добавятся экраны или статусы.
|
||||||
|
|
||||||
22
TODO/README.md
Normal file
22
TODO/README.md
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
# TODO
|
||||||
|
|
||||||
|
Папка для короткого списка ближайших и среднесрочных задач, которые уже обсуждались и пока отложены.
|
||||||
|
|
||||||
|
## Как использовать
|
||||||
|
|
||||||
|
- Один markdown-файл = одна задача.
|
||||||
|
- В файле коротко фиксируем:
|
||||||
|
- зачем это нужно;
|
||||||
|
- что именно сделать;
|
||||||
|
- что уже есть в коде;
|
||||||
|
- откуда продолжать;
|
||||||
|
- какие документы потом надо обновить.
|
||||||
|
- Это не активная разработка. Тут только план и контекст.
|
||||||
|
|
||||||
|
## Текущие задачи
|
||||||
|
|
||||||
|
- `2026-06-26_1800_graceful_shutdown_30s.md` - дать сервису до 30 секунд на корректное завершение опасных операций перед рестартом.
|
||||||
|
- `2026-06-26_1805_server_to_server_ws_and_dm_sync.md` - постоянный server-to-server WebSocket, push новых блоков и DM, ACK и backfill.
|
||||||
|
- `2026-06-26_1810_qr_device_sessions.md` - довести подключение других устройств по QR и перевести это в нормальные типизированные сессии.
|
||||||
|
- `2026-06-26_1815_esp32_file_storage.md` - использовать ESP32 как личное файловое хранилище для переписок и вложений.
|
||||||
|
|
||||||
@ -1,2 +1,2 @@
|
|||||||
client.version=1.2.279
|
client.version=1.2.280
|
||||||
server.version=1.2.259
|
server.version=1.2.260
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user