Putting computer/phone to sleep turns auto-syncing into one-way feature, auto-sending changes but not auto-receiving changes

[rmunn]

Describe the bug
When running FW Lite on both Android (v2025-12-03-9cc9b680) and desktop (v2025-12-12-505f4b21), both opening the same project from Lexbox, the auto-sync feature works smoothly from Android to desktop but doesn't feel smooth from desktop to Android.

Specifically, if I edit a word on the Android app, as soon as I close the entry window, the change I've just made appears on the desktop app within a second or two. But when I make an edit on the desktop app, the Android app doesn't automatically receive the change until I go into the Synchronize window of the Android app and download the Harmony commits. The app can see that the commits are present in Lexbox, but even though the button on the Synchronize dialog is labeled "Auto syncing", the Android app doesn't seem to actually pull down changes automatically. Instead, I have to press the sync button in the app, at which point the changes appear in the app.

To Reproduce
Steps to reproduce the behavior:

1. Load the same CRDT project in FW Lite for Windows and for Android
2. Click on an entry (say, the word "a" in Sena-3 with the English gloss "ASSOC" and definition "of"). Load it in both Windows app and Android app.
3. Edit word in desktop app, change to "ab". Notice Android app has not received the change yet.
4. In Android app, click Synchronize button. Button in dialog is labeled "Auto syncing" but you have to press the button to receive changes.
5. In Android app, after receiving the "a -> ab" change, make another change, changing "ab" to "abc".
6. Look at Windows app while closing the entry dialog in Android app. Notice "abc" change appears within seconds on the Windows app.

Expected behavior
When the synchronize dialog button says "Auto syncing" in the Android app, I would not have to press it to automatically receive CRDT commits from the Lexbox server.

[rmunn]

@myieye has mentioned that he's seen the auto-sync somehow stop receiving changes from others, i.e. something causes the event subscription to stop receiving events. He hasn't yet been able to narrow that down, but there's a possibility that this isn't just Android-specific behavior.

[rmunn]

https://stackoverflow.com/q/40502921 might be relevant: that person is seeing websockets getting closed after 100 seconds even in the presence of keepalive pings. I'll look into it and see if that's our situation or if that person was running into a different bug.

[rmunn]

Seems to happen on Windows too. Common factor seems to be having the app open for a long time. If the app has been recently opened then auto-syncing is bidirectional on Android and on Windows. If the app has been open overnight, the auto-sync stops, and you have to go hit the Synchronize button to sync up your changes.

[rmunn]

With Android, putting the phone to sleep (by pressing the power button) and then waking it up will break the downwards autosync but not the upwards one. If I put my Android phone to sleep then wake it up again, I see the following:

• Make a change in Android. Tap into another field, and change automatically appears in Windows.
• Make a change in Windows. Click into another field, and change does NOT automatically appear in Android.
• In Android, tap on Auto-syncing button. Change gets pulled down.
• Make another change in Windows. Click into another field, and this change also does NOT automatically appear in Android.

So once the ability to receive incoming changes has been lost (such as by suspending the phone), it seems the only way to get it back is to exit the Android app and restart it.

[rmunn]

Same thing happens on Windows if you put the laptop to sleep: the ability to receive sync events is lost.

Interestingly, if you then make a change in the app that lost the ability to receive sync events, when it sends the change to Lexbox it will receive any pending changes, so as long as you're actively editing your data you might not even notice that the incoming events have stopped triggering. But it's definitely putting the computer to sleep that triggers this. (There might be other triggers, but that one is reliable: works every time to trigger the bug).

What I mean by that second paragraph is this sequence of events:

• Put Windows laptop to sleep.
• Awaken Windows laptop.
• Make change (say, to Lexeme field) in Android. Change gets auto-synced upwards. (I can tell because my Linux laptop, which I did not put to sleep, auto-receives it). Windows laptop, which went to sleep, does NOT receive the change.
• Change different field in Windows. (Say, citation field). Citation change gets pushed, and Windows also suddenly updates Lexeme field with change from Android app. (Linux laptop has auto-updated both changes, so I know they're getting pushed).

[rmunn]

I suspect the issue is indeed the websocket being closed. In LexboxProjectService.cs we handle the Closed event on a websocket by disconnecting our end of the connection and removing it from the IMemoryCache that is caching the connections (line 272, inside StartLexboxProjectChangeListener). But websockets can receive the Closed event for many reasons, many of which will carry an Exception with the Closed event. So we should probably look at the Exception that we received and do something with it, such as try to reconnect. (With the standard exponential-backoff retries, and so on).

[rmunn]

Did some experimenting today. The SignalR HubConnection client is automatically reconnecting, but the connection IDs are different.

Before suspending laptop: id=a2Y39r5x6SN3KmJt8vBKRw

[fw-lite:web] info: Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport[1]
[fw-lite:web]       Starting transport. Transfer mode: Text. Url: 'wss://lexbox.org/api/hub/crdt/project-changes?id=a2Y39r5x6SN3KmJt8vBKRw'.

After suspending laptop: id=cpSg6Z5GdkX0Nb5IDQ7N9g

[fw-lite:web] info: Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport[1]
[fw-lite:web]       Starting transport. Transfer mode: Text. Url: 'wss://lexbox.org/api/hub/crdt/project-changes?id=cpSg6Z5GdkX0Nb5IDQ7N9g'.

I wonder if the connection IDs being different means that it has lost its OnProjectUpdated event handler? I'll try detecting the reconnection event and re-registering the event handler.

[rmunn]

It looks like the event listener is still connected on the client, but because the HubConnection ends up generating a new connection ID, the server isn't sending the project-changed event. Here's the code from CrdtProjectChangeHub.cs:

public async Task ListenForProjectChanges(Guid projectId)
{
    await permissionService.AssertCanDownloadProject(projectId);
    await Groups.AddToGroupAsync(Context.ConnectionId, ProjectGroup(projectId));
}

So the connection ID is being used to register the connection in the group. New connection ID, server thinks you're someone else and doesn't send you the notifications any more.

[rmunn]

The following change, resubscribing to project events whenever the HubConnection gets reconnected, worked:

diff --git a/backend/FwLite/FwLiteShared/Projects/LexboxProjectService.cs b/backend/FwLite/FwLiteShared/Projects/LexboxProjectService.cs
index ff7ee6427..7a7449deb 100644
--- a/backend/FwLite/FwLiteShared/Projects/LexboxProjectService.cs
+++ b/backend/FwLite/FwLiteShared/Projects/LexboxProjectService.cs
@@ -218,6 +218,12 @@ public class LexboxProjectService : IDisposable
         var lexboxConnection = await StartLexboxProjectChangeListener(server, stoppingToken);
         if (lexboxConnection is null) return;
         await lexboxConnection.SendAsync("ListenForProjectChanges", projectData.Id, stoppingToken);
+        lexboxConnection.Reconnected += (newId) =>
+        {
+            logger.LogInformation("Reconnected with new ID {newId} so calling ListenForProjectChanges again", newId);
+            return lexboxConnection.SendAsync("ListenForProjectChanges", projectData.Id, stoppingToken);
+        };
+
     }

     private static string HubConnectionCacheKey(LexboxServer server) => $"LexboxProjectChangeListener|{server.Authority.Authority}";

It resubscribed too often (I saw two consecutive log entries in short succession about reconnecting with a new ID after I had suspended my laptop for 30+ seconds), but it worked.