Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offline db out of sync #4664

Open
mpfau opened this issue Oct 13, 2022 · 4 comments
Open

Offline db out of sync #4664

mpfau opened this issue Oct 13, 2022 · 4 comments
Labels
bug broken functionality, usability problems, unexpected errors no-repro bugs that don't have a reproduction yet topic:offline issues with the offline database of the native clients

Comments

@mpfau
Copy link
Contributor

mpfau commented Oct 13, 2022

On my machine, the offline DB got out of sync. The same mail is displayed in the Trash and Inbox folders. I can't delete this mail from the Inbox anymore as it is always fetched from the Offline db.

We assume that this happened after a websocket event for an EntityUpdate (move mail to trash) was missed.

Discussion during Refinement on Oct 18:
We had missing ws updates for entity events because of the server migration. This caused some undeletable emails. It seems that there were such emails before but maybe for another reason.

  • Do we currently have a strategy to detect missed events?
  • Theoretically can happen if some WS message got lost.
  • previously, we loaded 1000 events before the last processed one
  • proposal: give updates a proper sequence number so the client can detect gaps
    • how to do that? will it scale to multiple servers?
    • can ws message get lost? https://stackoverflow.com/a/32475028/1923879
      • guarantees order: if we miss one, we won't receive another until the missed one is retransmitted
    • if we had sequence number: we could detect missing events in websocket session. Instead of processing the event we would re-initialize since the last processed one instead. For this we don't need to record/persist sequence numbers, it is enough to have them consistent in the WS session.
  • let the client download all events since the last one it recorded (only needs timestamp)
  • we could build mitigation: when we try to modify/delete email and get 404 we just nuke it from DB
    • this would be the first use case to move away from read-only cache, so may be worth more design effort

Further Actions

  • We must investigate what happens with unreliable WS connections: can the server send messages that the client never receives without the server noticing
  • is there an error thrown that we don't handle properly
  • Check event optimization in the client
  • Ask if this may be only related to the infra migration (did this happen before about Oct 10)
  • what is with missed CREATE events. We may have mail on the server that's just not shown because the cache thinks it has everything.
@mpfau mpfau added the bug broken functionality, usability problems, unexpected errors label Oct 13, 2022
@ganthern ganthern added the topic:offline issues with the offline database of the native clients label Oct 19, 2022
charlag added a commit that referenced this issue Oct 21, 2022
We'll need it later to delete everything for the groups we are not in
anymore.

We empty the tables instead of migrating them because we want to remove
them anyway due to corruption (see #4664)

#2874
charlag added a commit that referenced this issue Oct 25, 2022
Add ownerGroup column to offline db.

We detect the relationship change by the update of the user. We track
current user in cache storage because it already was receiving it in
case of offline storage and storage already had appropriate lifecycle
for it.

We empty the tables instead of migrating them because we want to remove
them anyway due to corruption (see #4664)

fix #2874
charlag added a commit that referenced this issue Oct 27, 2022
Add ownerGroup column to offline db.

We detect the relationship change by the update of the user. We track
current user in cache storage because it already was receiving it in
case of offline storage and storage already had appropriate lifecycle
for it.

We empty the tables instead of migrating them because we want to remove
them anyway due to corruption (see #4664)

fix #2874
@alstr
Copy link

alstr commented Dec 14, 2022

This is a major problem that is making it very difficult to continue to use Tutanota. This problem has cropped up several times now over the last couple of months and today I have more emails in my iOS inbox showing as "cannot be displayed", nor can they be deleted, and whenever I open the app and the emails reappear it messes up the new email count on the macOS app. Removing apps and local files is not a practical day to day solution when it occurs at this frequency. At the moment I am finding offline mode to be more of a problem than a solution. Please fix this as a priority over adding new functionality.

@charlag
Copy link
Contributor

charlag commented Dec 15, 2022

thanks for the info. We are still trying to find out in which cases it happens.

@alstr
Copy link

alstr commented Dec 15, 2022

In my case it's pretty frequent. I've given up trying to maintain the drafts folder.

@charlag
Copy link
Contributor

charlag commented Feb 9, 2023

I experience the same problem with the undeletable mail but we are not sure how to reproduce it yet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug broken functionality, usability problems, unexpected errors no-repro bugs that don't have a reproduction yet topic:offline issues with the offline database of the native clients
Projects
None yet
Development

No branches or pull requests

4 participants