UI thread is blocked when display goes into power saving mode
This sounds insane, so bear with me.
When sending a message from Briar Android to Briar Desktop, Android shows the message as sent and acked immediately, as expected. But when the desktop's screen is locked it takes several minutes for Android to show the message as sent, and several more minutes to show it as acked.
To check that my laptop wasn't suspending when the screen was locked, I added some debugging code to log a message once per second. The messages were logged regularly, confirming that the laptop wasn't suspending.
Then I modified the debugging code to also post a task to the EventExecutor once per second to log a message on the UI thread. When the screen was locked, the messages from the background thread continued to be logged, but the messages from the UI thread didn't. The tasks posted to the UI thread didn't run until the screen was unlocked, at which point all the tasks ran in quick succession. It seems that the UI thread is blocked while the screeen is locked.
Why does this cause problems for message sync? Because events are delivered on the UI thread. When the UI thread is blocked, no events are delivered, so the sync session doesn't properly react to records received from the Android peer.
The Android peer offers the message and the desktop peer receives the offer, but due to events not being delivered it doesn't send a request. Eventually, by chance, the Android peer briefly loses connectivity, the connection is lost and a new connection is made. The desktop peer's UI thread is still blocked, but the new sync session finds the offered message ID in the DB and sends a request without needing to use any events. The Android peer responds by sending the message. The desktop peer stores the message and marks it as needing an ack, but due to events not being delivered, it doesn't immediately send an ack. Eventually the Android peer loses connectivity again, another new connection is made, the desktop peer's new sync session finds that the message still needs an ack, and it sends one.
I'm using XFCE and XOrg on Debian Buster, with xflock4 for screen locking. I'd be interested to know whether it's possible to reproduce the bug on other setups.