Scott T.

@jcrum116 I checked your account and while it is indeed active, I found another account with your same domain that is connected to an old legacy business account that is not active (last updated 8 years ago). So you appear to have received that email correctly, but probably completely forgot that this old legacy business account even exists. We are removing very old deactivated businesses that have been deactivated for many years at this point. It would be a decent amount of engineering effort to try to update all these accounts which are likely never going to be reactivated. But we wanted to make sure and sent out the email to let users decide if they want to take any action.

@Ali1 The issue should be resolved in 10.58, which is being released now. You can get it now from our website. Otherwise, it will roll out to everybody over about a week.

My comment was responding to others regarding statements of data lost. Changes are saved by the web client into local storage in the browser. If there is an interruption to the service, those changes are stored locally and will be synced back when the web client reconnects to the service. But you shouldn't see any interruption in the web client if it is already open. It's a single-page application that is running locally in the browser, so would continue to function. You would only see the "Evernote is temporarily unavailable" page if you happen to be trying to log in or load the web client during the maintenance window. Even still, as long as you aren't blowing away your browser cache, it should sync the changes next time you open the UI.

FWIW, I seemed to have found a workaround while testing the bug and fix. If you edit the note, then leave and come back to that note, it should enable the template button.

@gazumped If you are able to identify a specific note that it occurs with, please reach out to me in a DM. I could work with you to determine if there's an issue going on in the backend.

Just an update that we pushed some more changes that should further reduce this issue. There was a case where intermittent large calls could trigger the issue for a set of users on the same server (serving a subset of prod users). We'll be continuing to work on performance improvements.

@realistdreamer I was looking at our connection logs today and I see large bursts of traffic coming from various API keys. This seems to indicate that on update failure, third party clients are retrying over and over again, sometimes multiple times a second. API keys have limits on the number of calls per user per key. So if the client does not implement a retry backoff strategy, it can very quickly hit the rate limit. Our devs were discussing the issue today and we'll be talking to product as well about what to do next. But in the meantime, it seems that evaluating your retry logic would be a good way to handle the problem for now.

Looks like we have a client fix for it already and I can't reproduce any more on the internal build with the fix. I'll push for this to get into the next release.

My team is looking into the inconsistent availability of the "Save as template..." link.

If anybody wants the super-technical deep-dive, YJS is a Conflict-free Replicated Data Type (CRDT), which is the technology we use for real-time editing. We work directly with the creator of YJS and sync regularly with him.

@gazumped I think all of those updates should require locking the note, so it would potentially have an issue if it was running while an RTE session was active.

Thanks @gazumped, that's unfortunate 😞 . I will circle back with the team.

@agsteele is basically right, @realistdreamer. If there is an active RTE session on a note, an update via our API will fail due to the note being locked for writing by the RTE session. The session holds the lock due to the constant real-time updates being sent to the server and applied to the note. Allowing updates from "legacy clients" during an RTE session would be very bad since the server could not properly resolve conflicts between an ENML update and an RTE update. I'm asking the team about next steps here and suggestions for a fix. I'd presume implementing a retry/backoff style logic would probably work for now, but I'm not the expert on RTE or your specific implementation. I will get back once I have more information.

Yeah, the dev site is woefully out-of-date. 😞 What specific issues are you seeing? I will ask if we have information or a contact I can get you in touch with.

The team made more improvements yesterday and our system metrics look significantly better. So far we have not been able to reproduce the "syncing temporarily paused" issue today. We're continuing to make performance improvements, but let me know if this issue persists. We think it's possible you may see this rarely still, but the likelihood should be reduced significantly.

Likely. I've asked the team to investigate. If the client has an issue reaching the RTE service backend, it would display the "Syncing temporarily paused" message. Changes are being saved locally and it will attempt to reconnect and then sync the changes, so you wouldn't see any data loss. Worst case is that if you are actively working on a note with multiple people, you temporarily won't see their real-time activity.

I'm reaching out to the team regarding the "Sync temporarily paused" issue. One of our QA is also observing this.

This was during the normal weekly release we have. Shouldn't have lasted more than a few minutes. The web client should be saving in the background, so hopefully you wouldn't lost many changes. We actually have a team actively working on a solution which should eliminate the downtime we've always had with our weekly release of the web client and backend.

I hope so. I know the mobile team was previously investigating background push for both Android and iOS. However, not sure the current status of that, but I hope it would be prioritized along with the switch to push sync since they basically go hand-in-hand. I'm currently managing backend systems, so less involved with the client development than I was previously.

As Federico noted, we were having some scaling issues to work through, but we scaled up one of our systems (for caching) and added memory, which allows latency to drop significantly. The team is continuing to work on performance.

Thanks, it definitely wasn't easy for the team since it brought a fair amount of additional complexity. They discussed the amount of work it would be and whether RTE would be the time to consider deprecating all legacy clients. It was decided "No", at least not at that time.

I can't give you an honest answer since I wasn't involved in that decision, but I agree that it does not make sense. I think it may have been to appease older customers who were used to having the sync button in legacy clients. But why only mobile, I am not sure. When we're ready to deliver the next upcoming sync improvements, everything should be getting pushed to new clients in real-time (versus the majority pull/polling mechanism in current clients). At that point, a sync button really doesn't make any sense since clients should never be more than a few seconds behind the latest version unless they have been offline for a significantly long time. The behavior should be the same as an email client. Updates just show up automatically as they're pushed to your device.

Legacy clients were taken into account when developing the new note format. Though legacy clients will not be able to do real-time editing, the service does keep an ENML version of the note up-to-date for backward compatibility. Furthermore, we still manage "note locking" such that legacy clients will be able to edit the note and you won't get note conflicts due to simultaneous editing by an RTE-capable client. There should be a message that shows up in a legacy client regarding an RTE client editing the note.

I'm asking the main dev that worked on the Tasks/RTE integration to investigate. I appreciate the bug report. If you can provide any additional details that might help us to debug, that would be great. There was a change with RTE for how things work in our backend in regards to displaying task data in the task overview pane. So there's possibly a bug there we missed. Are you making changes to the tasks in the note, and those don't get reflected in the overview? What about the reverse: making changes in the overview, are they reflected in the note?

This is expected. RTE introduces a new format for notes that allows for the Real-Time Editing feature to work and instantly sync changes. When you first open an older note, we need to run a conversion which can take a bit longer than normal. Once a note has been converted, load times should return to normal. I think what you would see in this case is that the first device would convert the note to the new format. Subsequent devices opening that note would need to re-fetch the newly converted note vs. opening the local copy which would still be in the old format. Again, should be a one-time slowdown.