Problem
WebSyncClient::force_resync() (#93 companion) re-announces every topic and sends a your_last_db_version = 0 version vector per (group, connected peer). On ephemeral clients (connect/connect_with_config, store: None) the VV leg silently does nothing: both version-vector send helpers early-return when the group has no store. This predates force_resync — ephemeral clients have never initiated VV catch-up; they rely on inbound pushes and the peer's own catch-up initiative — so force_resync inherits the gap rather than introducing it. Documented as a caveat in REQUESTS.md's #93 entry.
Why it's a design question, not a quick fix
The early-return exists because your_last_db_version is read from the persisted per-peer cursor, which an ephemeral client doesn't have. But an ephemeral client could legitimately send your_last_db_version = 0 unconditionally (it genuinely wants everything — that's what "ephemeral" means on reconnect), at the cost of a full changeset transfer on every force_resync/connect. Deciding whether ephemeral clients should (a) always request full sync, (b) keep an in-memory session cursor, or (c) stay push-only is a small design choice with bandwidth implications.
See web_engine.rs send_version_vector/send_version_vector_swarm (the store: None early-return) and the ForceResync handler.
Problem
WebSyncClient::force_resync()(#93 companion) re-announces every topic and sends ayour_last_db_version = 0version vector per (group, connected peer). On ephemeral clients (connect/connect_with_config,store: None) the VV leg silently does nothing: both version-vector send helpers early-return when the group has no store. This predates force_resync — ephemeral clients have never initiated VV catch-up; they rely on inbound pushes and the peer's own catch-up initiative — so force_resync inherits the gap rather than introducing it. Documented as a caveat in REQUESTS.md's #93 entry.Why it's a design question, not a quick fix
The early-return exists because
your_last_db_versionis read from the persisted per-peer cursor, which an ephemeral client doesn't have. But an ephemeral client could legitimately sendyour_last_db_version = 0unconditionally (it genuinely wants everything — that's what "ephemeral" means on reconnect), at the cost of a full changeset transfer on every force_resync/connect. Deciding whether ephemeral clients should (a) always request full sync, (b) keep an in-memory session cursor, or (c) stay push-only is a small design choice with bandwidth implications.See
web_engine.rssend_version_vector/send_version_vector_swarm(thestore: Noneearly-return) and theForceResynchandler.