Message read status not syncing properly on mobile #8041
Comments
JSkier21
added
the
bug
BijinDev
added
android
|
We did some testing. This occurs on both Android and iOS because we directly insert Mail instances into the cache from native. Since we don't update ranges on insertion, this Mail instance is outside of the our cached range (thus storage.isElementIdInCacheRange returns false from DefaultEntityRestCache#processCreateEvent), and thus we don't try to redownload the mail. As a result, the Mail instance may not get marked as read if you read it on another client. |
|
We did debug a bit more and we were puzzled why email is not in the cached range since mail indexer does use that range and We found one such case: when there's a new mail bag, the app would not a cached range for it since it never did mail indexing for it. We experimented with adding a fallback check for a single entity but it adds ~3ms delay on Android and ~8ms delay on desktop for each entity update which quickly adds up and we don't think that we want to go with this solution. We are trying to think of more options, e.g. storing this not as a mail entity but they all have drawbacks. |
Notification process on mobile does insert Mail instances into offline db in order to show the mail preview as quickly as possible when the user clicks on notification. In most cases it happens before login, and it happens independently of entity update processing. EntityRestCache does only download new list element instances when they are within the cached range. In most cases new mails are within the cached range as mail indexer caches mail bag ranges during initial indexing. However, if the mail bag size has been reached there will be a new mail bag with mail list that is not cached by the client (there is no range stored for this new list). EventQueue optimizes event updates. If CREATE event is followed by an UPDATE event they will be folded into a single CREATE event. In a situation where the email has been updated by another client after it has been inserted into offline db by notification process but before the login, and that email belongs to uncached mail bag, CREATE event (and optimized away UPDATE events) for that mail would be skipped and the user would see an outdated Mail instance. We changed the behavior for Mail instances to be always downloaded on CREATE event when we use Offline cache so that we do not miss those update operations. This was the previously expected behavior because of mail indexing and is also a common behavior now, until new mail bag is created so it does not lead to additional requests in most cases. Alternatively we could check if the (new) instance is already cached as individual instance. We decided against that as it adds the delay to event processing and also does not fit the logic of processing (why should cache check if new instance is already cache?). In the future we should try to optimize loading of new instances so that the sync time does not increase from downloading single emails. Close #8041 Co-authored-by: ivk <ivk@tutao.de>
charlag
changed the title
Notification process on mobile does insert Mail instances into offline db in order to show the mail preview as quickly as possible when the user clicks on notification. In most cases it happens before login, and it happens independently of entity update processing. EntityRestCache does only download new list element instances when they are within the cached range. In most cases new mails are within the cached range as mail indexer caches mail bag ranges during initial indexing. However, if the mail bag size has been reached there will be a new mail bag with mail list that is not cached by the client (there is no range stored for this new list). EventQueue optimizes event updates. If CREATE event is followed by an UPDATE event they will be folded into a single CREATE event. In a situation where the email has been updated by another client after it has been inserted into offline db by notification process but before the login, and that email belongs to uncached mail bag, CREATE event (and optimized away UPDATE events) for that mail would be skipped and the user would see an outdated Mail instance. We changed the behavior for Mail instances to be always downloaded on CREATE event when we use Offline cache so that we do not miss those update operations. This was the previously expected behavior because of mail indexing and is also a common behavior now, until new mail bag is created so it does not lead to additional requests in most cases. Alternatively we could check if the (new) instance is already cached as individual instance. We decided against that as it adds the delay to event processing and also does not fit the logic of processing (why should cache check if new instance is already cache?). In the future we should try to optimize loading of new instances so that the sync time does not increase from downloading single emails. Close #8041 Co-authored-by: ivk <ivk@tutao.de>
|
Possibly related to the long-standing issue #4265 Offline mode in general is very brittle and the local database seems to get corrupted very easily, leading to inconsistencies between devices. |
|
I'm still having issues on the latest iOS version, 259.241213.0. The workaround is to set the cache to 0, which means no offline mode. It's very reproducible, set cache to 2 days (or however many), and it doesn't sync read status correctly across devices for that period of time set. I wanted to add, as a paying customer, I worked with support initially on this. They were very dismissive, and didn't have much desire to work on this. This is very frustrating to see that Tuta seems to be focused on heavy marketing, and making more products (a separate calendar, for example), when they should be focusing on the core, making the existing e-mail service reliable and solid enough to work as expected. |
100%. Support only seem to be interested in workarounds and the outlook of Tuta is almost entirely focused on the 'next big thing'. I know this is not directly related to the issue at hand, so I won't go into it further - but previous constructive efforts have felt like shouting into the void anyway, and patience is wearing thing. #4265 is years old and hasn't had a Tuta response since 2023. |
|
Hi @JSkier21 Sorry for the inconvenience 🙏 and happy holidays :) |
I will request features on forum or via support.
Bug in mobile app
Describe the bug
Message read status across iOS devices is not syncing with the web application, very delayed or broken. This appears to be one way, for example, if I click mark the message as read on iOS, it will almost instantly show up in the web application on the browser. However, this is not the case at all when marking a message read in the browser to iOS devices. Note, I do have a couple of dozen mailbox rules, and also folders. Quitting and restarting the iOS app a couple of times gets things to sync in the root inbox, however, not the case with any folders I can see.
I have tried leaving the app open, previously hoping things would sync, It's been several hours, and they don't until I manually mark them as read in iOS.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Inbox and folders should sync relatively quickly across platforms. When I mark a message as read in the web applications, it should show up relatively quickly as marked read on iOS devices.
Changes strictly made on Apple devices, do, in fact, sync the read status correctly. With the web application, I would expect changes in the browser to sync across to iOS. However, they do not.
Screenshots
Web application showing messages as marked as read (red = read, Freudian slip 😅):
iOS application, same folder, showing 3 of the same messages marked as unread (note that badge count is accurate at zero though):
Smartphone (please complete the following information):
Additional context
Other than the above, not much else I have, happy to provide any details if you ask.
Test notes
The text was updated successfully, but these errors were encountered: