Files
netbird/management/server/testdata/sync_request_wire/README.md
mlsmaycon 3f4ef0031b [management] Skip full network map on Sync when peer state is unchanged
Introduce a peer-sync cache keyed by WireGuard pubkey that records the
NetworkMap.Serial and meta hash the server last delivered to each peer.
When a Sync request arrives from a non-Android peer whose cached serial
matches the current account serial and whose meta hash matches the last
delivery, short-circuit SyncAndMarkPeer and reply with a NetbirdConfig-only
SyncResponse mirroring the shape TimeBasedAuthSecretsManager already pushes
for TURN/Relay token rotation. The client keeps its existing network map
state and refreshes only control-plane credentials.

The fast path avoids GetAccountWithBackpressure, the full per-peer map
assembly, posture-check recomputation and the large encrypted payload on
every reconnect of a peer whose account is quiescent. Slow path remains
the source of truth for any real state change; every full-map send (initial
sync or streamed NetworkMap update) rewrites the cache, and every Login
deletes it so a fresh map is guaranteed after SSH key rotation, approval
changes or re-registration.

Backend-only: no proto changes and no client changes. Compatibility is
provided by the existing client handling of nil NetworkMap in handleSync
(every version from v0.20.0 on). Android is gated out at the server because
its readInitialSettings path calls GrpcClient.GetNetworkMap which errors on
nil map. The cache is wired through BaseServer.CacheStore() so it shares
the same Redis/in-memory backend as OneTimeTokenStore and PKCEVerifierStore.

Test coverage lands in four layers:
- Pure decision function (peer_serial_cache_decision_test.go)
- Cache wrapper with TTL + concurrency (peer_serial_cache_test.go)
- Response shape unit tests (sync_fast_path_response_test.go)
- In-process gRPC behavioural tests covering first sync, reconnect skip,
  android never-skip, meta change, login invalidation, and serial advance
  (management/server/sync_fast_path_test.go)
- Frozen SyncRequest wire-format fixtures for v0.20.0 / v0.40.0 / v0.60.0
  / current / android replayed against the in-process server
  (management/server/sync_legacy_wire_test.go + testdata fixtures)
2026-04-17 16:20:04 +02:00

1.6 KiB

SyncRequest wire-format fixtures

These files are the frozen byte-for-byte contents of the SyncRequest proto a netbird client of each listed version would put on the wire. server_sync_legacy_wire_test.go decodes each file, wraps it in the current EncryptedMessage envelope and replays it through the in-process gRPC server to prove that the peer-sync fast path does not break historical clients.

File Client era Notes
v0_20_0.bin v0.20.x message SyncRequest {} — no fields on the wire. Main Sync loop in v0.20 gracefully skips nil NetworkMap, so the fixture is expected to get a full map (empty Sync payload → cache miss → slow path).
v0_40_0.bin v0.40.x First release with Meta at tag 1. v0.40 calls GrpcClient.GetNetworkMap on every OS; fixture must continue to produce a full map.
v0_60_0.bin v0.60.x Same SyncRequest shape as v0.40 but tagged with a newer NetbirdVersion.
current.bin latest Fully-populated PeerSystemMeta.
android_current.bin latest, Android Same shape as current.bin with GoOS=android; the server must never take the fast path even after the cache is primed.

Regenerating

The generator is forward-compatible: it uses the current proto package with only the fields each era exposes. Re-run after an intentional proto change:

go run ./management/server/testdata/sync_request_wire/generate.go

and review the byte diff. An unexpected size change or diff indicates the wire format has drifted — either adjust the generator (if the drift is intentional and backwards-compatible) or revert the proto change (if it broke old clients).