From acad7966629f3d9f7757ac4fa1cf31a777190d95 Mon Sep 17 00:00:00 2001 From: nolen777 Date: Wed, 3 Dec 2025 20:45:58 -0800 Subject: [PATCH] Document Shardok resync mechanism and unused request_full_resync field (#4623) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The request_full_resync field exists in eagle.proto but is not read by the server. The actual resync mechanism uses filteredResultCount = 0 instead. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude --- docs/CONNECTION_ARCHITECTURE.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/CONNECTION_ARCHITECTURE.md b/docs/CONNECTION_ARCHITECTURE.md index 60601d54ca..c1773b6a18 100644 --- a/docs/CONNECTION_ARCHITECTURE.md +++ b/docs/CONNECTION_ARCHITECTURE.md @@ -387,12 +387,15 @@ ShardokViewStatus { - Sends duplicate updates (client sees repeated actions) - Skips updates (client misses actions) -**No visible state recovery mechanism** in the code: -- No "resync" request to get full game state +**State recovery mechanism (partial):** +- Client can request resync by setting `filteredResultCount = 0` in `ShardokViewStatus` +- Server will send all results from the beginning when `filteredResultCount = 0` +- ⚠️ **NOTE:** The `request_full_resync` field exists in the proto (`eagle.proto:88`) but is **NOT read by the server**. It's effectively dead code. The resync works via `filteredResultCount = 0` instead. - No checksum/hash to verify client and server are in sync -- No explicit handling of "I missed updates" scenario -**Impact:** After connection drop during Shardok, game state may be inconsistent. +**TODO:** Either implement server-side handling of `request_full_resync`, or remove the field from the proto. + +**Impact:** After connection drop during Shardok, client can recover via resync, but relies on `filteredResultCount = 0` workaround. ## Recommendations