fix(ear): messages can't be displayed - WPB-24136#4450
fix(ear): messages can't be displayed - WPB-24136#4450David-Henner wants to merge 3 commits intorelease/cycle-4.16from
Conversation
| ) | ||
|
|
||
| for envelope in envelopes { | ||
| try Task.checkCancellation() |
There was a problem hiding this comment.
issue: if we processed some events, then cancel, we won't delete any of the events already processed, so next time the sync happens some events will be processed again. I think in the case of new message events this is fine as we have tolerance to reprocess such events. But I'm not sure that all events are like this.
Though... now I'm wondering if this is the case since we don't hit the databaseSaver.save() line. What do you think?
There was a problem hiding this comment.
In this commit:
- Added logic to handle the interruption of event processing, in order to delete processed events and save the database.
- Replaced
Task.checkCancellationby throwing when the database is locked and the envelope isn't background accessible. The reasoning is that if there's an ongoing call when going to the background, we don't cancel the sync, so the database key would be removed from cache but we'd continue processing events that require it
I think it starts to make the sync too complex with special cases for EAR, and another idea I had was to systematically cancel the sync when going to the background. And, in case there's an ongoing call, start a call events only sync.
What do you think ?
Test Results0 tests 0 ✅ 0s ⏱️ Results for commit 65166ca. Summary: workflow run #23242108485 |
|
2 participants
Issue
Sometimes, with EAR enabled, after opening the app, some messages can't be displayed.
Cause
Messages couldn't be encrypted at rest because the database key was missing.
This happens because the app went to the background and locked the database (nullified the database key from cache) while the incremental sync was running and processing messages.
When this happens, we cancel the sync
wire-ios/wire-ios-sync-engine/Source/UserSession/ZMUserSession/ZMUserSession+LifeCycle.swift
Line 46 in 48209b1
However, the cancellation doesn't get propagated properly from the suspend method to the inner sync task. Hence, the sync continues and tries to process messages while the database key is nil
Solution
NonReentrantTaskManagerandExpiringActivityTask.checkCancellationbefore processing individual events in the incremental syncTesting
Checklist
[WPB-XXX].