Jump to content

Scott T.

Ex Employees
  • Posts

    682
  • Joined

  • Last visited

  • Days Won

    23

Scott T. last won the day on May 15 2023

Scott T. had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Scott T.'s Achievements

662

Reputation

7

Community Answers

  1. @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.
  2. @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.
  3. 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.
  4. 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.
  5. @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.
  6. 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.
  7. @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.
  8. 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.
  9. My team is looking into the inconsistent availability of the "Save as template..." link.
  10. 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.
  11. @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.
  12. Thanks @gazumped, that's unfortunate 😞 . I will circle back with the team.
  13. @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.
  14. 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.
  15. 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.
×
×
  • Create New...