synchronization is very long

[fboucher]

In production, I have around 1500 post and the synchronization on the MAUI Android App process is very long.

It's going through all the posts one by one and freezing or blocking the UI.

Here what I'm expecting the "sync" does:

• Sync the Databases.
• Looking at the downloaded files. When related to a post that is READ, it should be deleted.
• Download file for the UNREAD posts, if it's not already present locally on the Android device.

the database may have 1000+ posts but there most of the time only ~10 unread. synchronization shouldn't be that long assuming the internet speed is good.

[fboucher]

Triage and implementation brief

Labels to apply: type:bug, app, go:yes, ready-for-agent

Type: performance bug in the MAUI app. Priority: high, because sync starts every time the Posts page opens.
When it happens (from the reporter): always after a fresh install or cleared cache, and sometimes after new posts are added on the web side.
Related, not duplicates: #196 (sync hanging, fixed in #202), #169 (local cleanup), #176 (progress bar).

Expected behaviour (unchanged from the issue)

1. Sync the database.
2. Delete downloaded HTML for posts that are now read.
3. Download HTML for unread posts that aren't stored locally yet.

With ~1500 posts but only ~10 unread, sync should be quick and must never freeze the UI.

Root causes found in src/NoteBookmark.MauiApp/Data/SyncService.cs (on v-next)

1. The full post list is fetched on every sync. PullAsync calls GetPostsModifiedAfter(DateTime.MinValue) (line 213), which downloads all ~1500 posts, unread and read (PostNoteClient.cs:193), even when lastSync is known. The full list is currently how server-side deletions get detected, so a fix has to keep deletion detection working.
2. Posts are saved one at a time. The pull loop (lines 233-313) calls GetPostAsync or SavePostAsync separately for each post. Each call does its own SELECT plus UPDATE/INSERT, with no transaction. LocalDataService.SavePostsAsync (line 88) already batches saves in RunInTransactionAsync and should be used instead.
3. There is one extra HTTP request for every unread post. apiClient.GetPost(id) runs for each unread post pulled (line 276). On a first sync that's a network round trip for every unread post.
4. Sync runs on the UI thread. Posts.razor:103 starts _ = StartBackgroundSync() from the Blazor dispatcher, so every continuation inside SyncService (mapping, dictionaries and loops over 1500 items) runs on the main thread. SyncProgressChanged also fires once per post (line 312), which causes a re-render through InvokeAsync + StateHasChanged for every post.

SyncHtmlAsync (lines 337-384) already prunes read posts and only downloads unread HTML that isn't cached, so it matches points 2 and 3 of the expected behaviour and needs no changes.

Suggested work

• Pull only the delta: call GetPostsModifiedAfter(lastSync ?? DateTime.MinValue). To handle deletions, pick one of these:

  • (a) Add a lightweight API endpoint that returns only the IDs of existing posts.
  • (b) Keep the full list only when there is no lastSync (first sync).

  (a) is preferred. If you choose (b), explain in the PR how deletions are caught after the first sync.

• Save pulled posts in one batch with SavePostsAsync, making sure it still preserves IsPendingSync for posts with local edits. Also mark server-deleted posts in one batch, not one post at a time.

• Avoid the extra GetPost request per post when PostL already has what the local DB needs. Otherwise, run those requests with limited concurrency (for example Parallel.ForEachAsync or SemaphoreSlim with 4-6 at a time).

• Move sync off the UI thread (for example Task.Run(() => client.SyncAsync()) in Posts.razor, or ConfigureAwait(false) throughout SyncService). Throttle progress events, for example every N posts or every ~250 ms.

Acceptance

• A fresh install with ~1500 posts syncs without freezing the UI, and the progress bar keeps moving.
• A sync after adding one post on the web pulls only that post (it doesn't re-save all 1500).
• Posts deleted on the server are still removed locally, and HTML for read posts is still pruned.
• New or updated tests in NoteBookmark.MauiApp.Tests/SyncServiceTests.cs cover delta pull, deletion detection and batched save.

Repo conventions (AGENTS.md)

Use a bug/issue-208-... branch, apply in-progress before starting, open the PR against v-next, and never merge.

---

Generated by Claude Code