-
fix(raft): snapshots dumped the wrong user tables — fatal on Postgres, silent data gap on SQLite
Release / frontend (push) Canceled after 0sRelease / linux (amd64) (push) Canceled after 0sRelease / linux (arm64) (push) Canceled after 0sRelease / windows (push) Canceled after 0sRelease / macos (push) Canceled after 0sRelease / release (push) Canceled after 0sBuild and Push Docker Image / build-and-push (push) Canceled after 0sreleased this
2026-06-12 13:29:09 +03:00 | 216 commits to main since this releasemanagedTables listed 'users'/'refresh_tokens', but the entities map to
'user_accounts'/'user_refresh_tokens'. SQLite swallowed the missing
tables (isNoSuchTable → 'empty'), so every snapshot ever taken silently
EXCLUDED accounts and sessions. Postgres aborts the transaction at the
first failed SELECT instead — no snapshot could ever complete, the raft
log grew without bound and the node burned CPU/disk retrying every ~80s
(plus checkpoint storms from the orphaned aborted transactions).- correct table names; probe HasTable before each dump/DELETE/restore
insert so a missing table can never poison the transaction on
Postgres (and legacy snapshots restore cleanly); - bridge: the receiver now applies batches on a context detached from
the HTTP request — a slow hub outliving the sender's timeout used to
do all the raft-apply work and then fail MarkApplied with 'context
canceled', so the same entries were re-shipped and re-applied
forever; the sender's ship timeout grows 10s → 90s to match reality
on fsync-bound disks.
Downloads
- correct table names; probe HasTable before each dump/DELETE/restore