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.

23 hours ago, JoeHoe said:

seriously?! is that how you treat paying customers? I don't want to lose ANY changes..

If you have a buggy version, don't use it in production, that's what beta channel is for...

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.

2 hours ago, realistdreamer said:

Is there any documentation of these changes and the new RTE format for developers?  This change is wreaking havoc on our app and we don't even know where to go for guidance as I see nothing on the developers site.

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.

8 hours ago, eric99 said:

Is this problem also caused by server overload? Many users have it last days:

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. 

18 hours ago, Dave-in-Decatur said:

And just now in the Web client (not desktop) I got the Red Triangle of Temporary Unavailability. Fortunately, it passed before I could even finish saving the screen snip.

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.

7 hours ago, Alxa said:

Does this mean, that the Android client will eventually get push sync for the widgets (updates of tasks / reminders in the background without client running)?

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.

6 hours ago, WilliamL said:

It was almost as if the system was clogged.

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.

13 hours ago, Boot17 said:

Being able to add RTE for the new clients while making it so that Legacy can still work with that is pretty great.

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.

7 hours ago, Dave-in-Decatur said:

There has been some discussion of how the Legacy Windows program (v. 6.25.3, I believe) would handle notes converted to the new format. Recognizing that this program is deprecated and unsupported by Evernote, but that nonetheless it is still in use, can you comment?

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. 

2 minutes ago, llabusch93 said:

Secondly, we have yet to receive feedback regarding the task synchronization issue in the main overview. On my Android client, the tasks displayed in the overview seem to be frozen in time, meaning they show outdated due dates or remain open despite being correctly checked off within the note itself.

What is causing this issue and when can we expect it to be resolved? For me, this occurs on the Android client, while the Linux desktop and web clients do not exhibit the problem.

I have already tried purging data, reinstalling the app, and submitting a support ticket.

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?