fix: invisible groups - WPB-20123 #3792

netbe · 2025-10-27T16:35:08Z

WPB-20123 [iOS] Invisible groups, channels and 1:1 chats with functioning push notifications

Issue

Sometimes conversations are not shown within the app. Some conversations were found not updated with data from backend for example having a invalid groupType hence not displayed.

Right now, the ConversationsRequestStrategy with the updateSync (KeyPathObjectSync) sync the conversation with the backend when the NeedsToBeUpdatedFromBackend property is set to true, but it does not wait for the request to finish to turn off the flag, so if the request fails or the app crashes, we'll never retry the request.

Solution:

Using WorkAgent in feat: introduce WorkAgent - WPB-20123 #3800, we remove old KeyPathObjectSync
ConversationUpdatesGenerator creates UpdateConversationItem workItems for the WorkAgent.
remove pullConversation from the mlsWelcomeMessage event processing so processing events are without extra network calls.

Other changes:

add logs for processing events

Testing

Create a group
See ticket being created and executed

Checklist

Title contains a reference JIRA issue number like [WPB-XXX].
Description is filled and free of optional paragraphs.
Adds/updates automated tests.

UI accessibility checklist

If your PR includes UI changes, please utilize this checklist:

Make sure you use the API for UI elements that support large fonts.
All colors are taken from WireDesign.ColorTheme or constructed using WireDesign.BaseColorPalette.
New UI elements have Accessibility strings for VoiceOver.

WireDomain/Sources/WireDomain/WorkAgent/Worker/SyncConversationsWorker.swift

netbe · 2025-10-30T21:28:23Z

WireDomain/Sources/WireDomain/Synchronization/ConversationUpdatesGenerator.swift

+    public func start() async {
+        fetchedResultsController.delegate = self
+        do {
+            try fetchedResultsController.performFetch()


this class monitors the coredata change, and create ticket for scheduler

netbe · 2025-10-30T21:29:43Z

wire-ios-data-model/Source/MLS/MLSService.swift

-                var epoch: Int64 = 0
-                if let context, let conversation = fetchConversationInfo(
-                    with: groupID,
-                    in: context
-                )?.conversation {
-                    epoch = Int64(conversation.epoch)


this part getting the epoch outside the CoreData context was failing on debug build

netbe · 2025-10-30T21:32:12Z

wire-ios-sync-engine/Source/Synchronization/SyncAgent.swift

    func performIncrementalSync() async throws {
-
+        Task {
+            await conversationsMonitor.start()


we start generating the conversation sync with backend tickets only after initial sync is finished, in order to avoid having conversations syncing twice (in Worker and in InitialSync)

suggestion: if the monitor is inside the worker, we could instead tell the workers to "start" and "stop" work. In this case, the conversation worker would start and stop monitoring. We could even add these start stop methods as optional protocol methods on Worker, then flip a flag on the work agent isAcceptingTickets or isOpen, which would then inform all its workers to start or stop. What do you think?

so workers would start when WorkAgent start to run, right?

in the case of conversations, I don't know if that would solve the issue where initialSync pulling conversations would create conversations with needsToBeUpdatedFromBackend = true and trigger the worker.

Did you mean that we should move setting needsToBeUpdatedFromBackend to true or false within the Worker?

johnxnguyen · 2025-10-31T08:17:52Z

WireDomain/Sources/WireDomain/Components/ClientSessionComponent.swift

+    }()

-extension InitiateResetMLSConversationUseCase: ResetBrokenMLSConversationDelegate {
+    public lazy var conversationMonitor: ConversationUpdatesGeneratorProtocol = ConversationUpdatesGenerator(


suggestion: if we say that the worker is responsible for keeping local conversations in sync with the backend, then I would expect the worker to be capable of monitoring the database and raising tickets autonomously. In which case, the worker retains the monitor, the monitor simply informs a delegate or via callback that there are objects that it detected, and the worker creates the ticket.

johnxnguyen · 2025-10-31T08:35:03Z

wire-ios-sync-engine/Source/Synchronization/SyncAgent.swift

    func performIncrementalSync() async throws {
-
+        Task {
+            await conversationsMonitor.start()


suggestion: if the monitor is inside the worker, we could instead tell the workers to "start" and "stop" work. In this case, the conversation worker would start and stop monitoring. We could even add these start stop methods as optional protocol methods on Worker, then flip a flag on the work agent isAcceptingTickets or isOpen, which would then inform all its workers to start or stop. What do you think?

…omBackend

netbe · 2025-11-05T11:31:49Z

WireDomain/Sources/WireDomain/WorkAgent/WorkItem/WorkItem.swift

    /// Cancel the work item.

-    func cancel() async
+//    func cancel() async


@johnxnguyen this is not implemented, I wonder if we keep it

github-actions · 2025-11-05T11:59:07Z

Test Results

21 files 1 225 suites 12m 57s ⏱️
9 362 tests 9 333 ✅ 28 💤 1 ❌
9 375 runs 9 347 ✅ 28 💤 0 ❌

For more details on these failures, see this check.

Results for commit 2524cb0.

♻️ This comment has been updated with latest results.

samwyndham

Looks good. I've just left a few comments

samwyndham · 2025-11-06T14:35:36Z

WireDomain/Sources/WireDomain/WorkAgent/WorkItem/UpdateConversationItem.swift

+        self.conversationID = conversationID
+    }
+
+    func start() async throws {


question (out of scope): @netbe @johnxnguyen Am I right that the way a WorkAgent has changed since we discussed it last Friday? The work now belongs to a WorkItem and not some other actor?

There were a few things that were nice about the old approach:

Less need to pass dependencies to the place that the work item is created.

Possibility to persist work item across app runs.

Anyway this is out of scope for this PR.

yes that's basically what change

samwyndham · 2025-11-06T14:36:32Z

WireDomain/Sources/WireDomain/WorkAgent/WorkItem/UpdateConversationItem.swift

+    var id = UUID()
+    var priority: WorkItemPriority {
+        .medium
+    }
+
+    var conversationID: WireNetwork.QualifiedID


question: Why are id and conversationID publicly mutable?

no reason, true I'll make it a let

samwyndham · 2025-11-06T14:40:02Z

WireDomain/Sources/WireDomain/Synchronization/ConversationUpdatesGenerator.swift

+        for type: NSFetchedResultsChangeType,
+        newIndexPath: IndexPath?
+    ) {
+        guard let conversation = anObject as? ZMConversation else { return }


suggestion: Crash if this fails. The fetched results controller is configured in this file so we know that anObject right?

github-actions bot assigned netbe Oct 27, 2025

netbe force-pushed the fix/invisible-groups-WPB-20123 branch from d95d9ff to 3b5f27c Compare October 30, 2025 21:14

netbe changed the base branch from release/cycle-4.8 to release/cycle-4.9 October 30, 2025 21:15

netbe changed the base branch from release/cycle-4.9 to feat/work-agent October 30, 2025 21:25

netbe requested review from johnxnguyen and samwyndham October 30, 2025 21:25

netbe commented Oct 30, 2025

View reviewed changes

WireDomain/Sources/WireDomain/WorkAgent/Worker/SyncConversationsWorker.swift Outdated Show resolved Hide resolved

netbe commented Oct 30, 2025

View reviewed changes

johnxnguyen reviewed Oct 31, 2025

View reviewed changes

johnxnguyen force-pushed the feat/work-agent branch from 89e0cdf to 87a55b8 Compare November 3, 2025 14:53

Base automatically changed from feat/work-agent to develop November 4, 2025 15:05

netbe added 2 commits November 4, 2025 21:34

remove ConversationRequestStrategy's updateSync of needsToBeUpdatedFr…

f79177e

…omBackend

write tests

99138f9

netbe force-pushed the fix/invisible-groups-WPB-20123 branch from 5361b25 to 99138f9 Compare November 5, 2025 11:28

netbe changed the base branch from develop to release/cycle-4.10 November 5, 2025 11:28

netbe commented Nov 5, 2025

View reviewed changes

Merge branch 'release/cycle-4.10' into fix/invisible-groups-WPB-20123

2342ce9

netbe marked this pull request as ready for review November 5, 2025 11:32

netbe added 2 commits November 5, 2025 22:49

fix doc

d8db4d1

fix test

28b3be7

netbe requested a review from johnxnguyen November 6, 2025 13:06

samwyndham reviewed Nov 6, 2025

View reviewed changes

Merge branch 'release/cycle-4.10' into fix/invisible-groups-WPB-20123

2524cb0

fix: invisible groups - WPB-20123 #3792

Are you sure you want to change the base?

fix: invisible groups - WPB-20123 #3792

Uh oh!

Conversation

netbe commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Issue

Testing

Checklist

UI accessibility checklist

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

samwyndham left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

netbe commented Oct 27, 2025 •

edited

Loading

github-actions bot commented Nov 5, 2025 •

edited

Loading