Problem (PROBLEMS.md N5)
SyncRequest::VersionVector and SyncResponse::ChangesetResponse have no version field. A new field or semantics change means old peers can't parse the message and (per CLAUDE.md §5) fail silently — sync just stops between mismatched versions, with no error. Rolling upgrades are unsafe.
Proposed approach (Phase 0)
Add a protocol_version field to the version-vector messages; negotiate the minimum common version. Bump the protocol identifier string in engine/snapshot_protocol.rs. This is a protocol change — write a short plan first and identify affected invariants per CLAUDE.md §1, and add a regression test in integration_bugs.rs.
Files
wavesyncdb/src/protocol.rs, wavesyncdb/src/engine/snapshot_protocol.rs, wavesyncdb/tests/integration_bugs.rs.
Ref: docs/research/sync-reliability.md §6 P1, PROBLEMS.md N5.
Problem (PROBLEMS.md N5)
SyncRequest::VersionVectorandSyncResponse::ChangesetResponsehave no version field. A new field or semantics change means old peers can't parse the message and (per CLAUDE.md §5) fail silently — sync just stops between mismatched versions, with no error. Rolling upgrades are unsafe.Proposed approach (Phase 0)
Add a
protocol_versionfield to the version-vector messages; negotiate the minimum common version. Bump the protocol identifier string inengine/snapshot_protocol.rs. This is a protocol change — write a short plan first and identify affected invariants per CLAUDE.md §1, and add a regression test inintegration_bugs.rs.Files
wavesyncdb/src/protocol.rs,wavesyncdb/src/engine/snapshot_protocol.rs,wavesyncdb/tests/integration_bugs.rs.Ref:
docs/research/sync-reliability.md§6 P1, PROBLEMS.md N5.