Refresh the conversation list while it is open - #6746
Draft
AndyScherzinger wants to merge 2 commits into
Draft
AndyScherzinger wants to merge 2 commits into
AndyScherzinger wants to merge 2 commits into
Conversation
With the list on screen, a message sent from another device shows up only when a push arrives or the user leaves the screen and comes back. That gap matters most for the people who have no working push at all - no Play Services, no UnifiedPush distributor - for whom nothing else refreshes the list while they are looking at it. Re-sync it every thirty seconds instead, matching the iOS timer. The loop is bound to the resumed lifecycle, so it cannot run behind the screen or outlive it, and it waits before the first sync rather than after: onResume already fetches, and syncing on entering the loop would fetch twice every time the screen is resumed. A tick is dropped while a sync is already in flight, so the loop can never queue behind itself, and while a search is open, where swapping the list out would move what the user is reading. Being offline and battery saver are deliberately not checked here: the first is already handled where the sync would make its request, and the second already stops the expensive half, the message catch-up it triggers. Every tick asks only for what changed, which is what makes a timer this short affordable at all. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
The loop fires whatever else is going on, so what decides whether the list stays usable is when a tick is dropped: one that is not dropped while a sync is running queues requests behind each other, and one that is not dropped during a search swaps the list out from under what the user is reading. The two cases pin each other down. A tick during an in-flight sync must leave the call count at one, and a tick after the previous sync finished must take it to two, so neither dropping every tick nor dropping none of them passes both. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
AndyScherzinger
force-pushed
the
feat/noid/conversation-list-background-sync
branch
from
September 21, 2026 20:23
abc0d72 to
7d19a5c
Compare
AndyScherzinger
force-pushed
the
feat/noid/conversation-list-foreground-sync
branch
from
September 21, 2026 20:23
008bbaf to
e931686
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With the list open, a message sent from another device only shows up when a push arrives or the user leaves and comes back. This adds the 30-second refresh timer iOS has, which matters most for the people who have no working push at all — no Play Services, no UnifiedPush distributor — for whom this becomes the only freshness mechanism the list has.
What it does
onResumealready fetches, and syncing on entry would fetch twice on every resume.What a reviewer should push back on
includeStatus, because with it the server returns every one-to-one room regardless ofmodifiedSinceand most of the saving disappears. iOS keeps status fresher here; this trades that for the request volume.Not in this PR
delete/disinvitesignaling messages, which would let the five-minute rule relax.🚧 TODO
🏁 Checklist
/backport to stable-xx.x🤖 AI (if applicable)