Is Dynalist Down?

Is Dynalist currently down for anyone besides me? It’s out-of-sync on all of my devices (I may have lost data…), and it fails to load quickly in ordinary browsers, too. I’m seeing this for the first time since I started using Dynalist back in the summer.

Tested on various devices. No Internet connection speed issues at my end. The Dynalist status page says everything is 100%, but that is not the case here.

It’s troubling when the top-right corner claims “synced”, yet data are out-of-sync. What can be done? I was just about to purchase the annual subscription. :slightly_frowning_face:

I’m definitely seeing slowness but syncing is still happening. However it’s taking much longer than normal. I don’t know if that’s any comfort or not :expressionless:

1 Like

Seems to have been an issue with the server starting ~2 hours ago. I made some changes 5 minutes ago and it seems to be improving.

4 Likes

Thanks. I’ve seen an improvement now too. I’d echo the concerns of others though that status page doesn’t reflect such drastic performance hits. Does it only measure total loss of service?

1 Like

Thank you, Shida, I can see it slowly improving as well. But it can sometimes take several manual reloads to get to the current status of a list. :slightly_frowning_face:

What’s particularly troubling to me is when the top-right corner of the webpage or the app claims Synced when, in fact, the data hasn’t been synced. I was looking at the same list on various devices, all of them claimed Synced in the top-right corner, even after manual reloads, yet the list was different on every device.

If at least the webpage/app reported Waiting for Sync or something like that, this wouldn’t be so disquieting. Hopefully, the reliability of the sync status can be improved in future.

(To that end, I would also welcome if the sync status were directly visible on mobile devices in the top-right corner, too, without our first having to tap the three-dot menu button to view the sync status. Thank you.)

The status page indeed only measures whether our service is reachable, not performance. Internally we have a few dashboards in the office that displays vital information about server performance, which we keep a close eye on as long as we’re awake. We also have things like email, text and phone calls setup for outages.

The impact of today’s issue was mostly that requests were taking an abnormal amount of time to be processed. I’m still in the middle of trying to fix things but at the worst, responses were taking an average of 10 seconds to be fulfilled, and individual requests sometimes up to 20-30 seconds.

Acknowledged. It can certainly be improved - right now “Synced” means any local changes has been pushed to the sync server, but not necessarily that the local view is fully up to date with remote. Originally it was done this way to avoid the annoyance of flashing sync symbols while they work.

We’ve certainly received enough feedback for the sync status on mobile - Still unsure what exactly to implement but there’s definitely room for improvement.

3 Likes

Thank you, Shida, it’s comforting to know that the Synced status does reflect that the data have been successfully submitted to the server. However, as you can imagine, it is certainly confusing and disconcerting to be viewing the same list on various devices, both devices claiming Synced status, yet the lists being different. Briefly, I was in panic mode, fearing data loss.

After you resolved the server issues, the items eventually appeared, but there could still arise syncing conflicts, couldn’t they, if I started editing a list, imagining it being “synced” as the status claimed, even though there was a different “synced” version on the server at the same time? If I continued editing the non-synced local version, wouldn’t it later overwrite the version on the server (or vice versa), leading to some data loss/distortion eventually, especially if I edited the same list items on various devices without them being fully in-sync at all times? :flushed: This can be worrisome.

As to the status indicator, I for one would welcome “traffic lights”. GREEN = fully synced; ORANGE = saved; YELLOW = sync in progress; RED = syncing paused/failed. As to it potentially distracting users through flashing, perhaps it could be a user option whether the sync status should be displayed directly or behind a menu button, and whether the sync status should be indicated as text or as “traffic lights”. I for one find the text-based sync statuses more distracting (more time-consuming to read) than color-based signals would be, but that may be just me. :wink: I imagine most of us would only ever see an alternation of green, orange & yellow in a color-based status indicator, and I for one wouldn’t find that distracting. (In fact, I believe it would be a time-saver for me, even if only measured in milliseconds.) :wink:

After some tinkering (also caused some slowness in the process), I have located the problem.

It’s a combination of our change to the real-time push system (using WebSockets) and Cloudflare. We used to send heartbeat messages every 30 seconds, which was recently changed to 60 seconds. It seems like Cloudflare terminates connections that doesn’t send any data within 60 seconds. This meant a lot of Dynalist clients were constantly being disconnected from the real-time push system, and reverting to the old “wait and check for changes” fallback loop, which caused significant server load when everyone does it at the same time.

I have changed the real time push system to send out heartbeats more often. This seems to have calmed down the storm and we’re resuming full capacity right now.

5 Likes

Thank you for that update and fix. And I’ve just set up annual instead of monthly payments for my renewal, coming up next week, because I trust you will get it running reliably in the long run.

(After half a year of using Dynalist, I can’t imagine getting back to a “life without Dynalist”. :flushed: And nope, Workflowy wouldn’t be a full-fledged replacement for me.)

1 Like

@Shida Unfortunately, I’m still experiencing syncing issues. :worried: It’s not as bad as a few days ago when I started this thread, but the Synced status in the mobile app still doesn’t correspond to reality.

Earlier today, I made some edits in some of my lists in the Android mobile app. I made sure to wait for the Synced status to light up before I put the app into the background. (Yes, I had to tap the menu button manually to view the sync status – I wish it was permanently visible.)

When I later opened the same lists in Chrome on my desktop machine, only fragments of my edits from the mobile app were visible. :worried: For example, one of the words only appeared with its first few letters, and then was cut off. Some list items I added in the mobile app failed to appear on desktop completely. Refreshing on desktop made no difference. When I reopened the mobile Android app, the missing items were there. I made another manual refresh in the mobile Android app, and only then, the items also appeared on desktop.

I hope you can address these sync quality issues in future, because this can lead to serious data loss. :anguished: I’m afraid the current Synced status as displayed in the mobile app, is partly fictional – it really is no guarantee that the data have been successfully synced with the server. (I made those edits in the mobile app some 10 minutes ago, yet even after 10 minutes, they did not appear on desktop, until I made another manual refresh in the mobile app.)

Hmm that’s weird. I can’t think of any reason why that would happen as the mobile app uses the exact same code to sync as the desktop/web versions.

When you say you made a manual refresh of the app, what exactly did you do? Were you able to check the version history to verify that it only synced the moment you refreshed it?

I have a suspect that it’s due to the backgrounding of the app, and somehow reactivating it might be interfering with the timers behind syncing.

And just to make sure, the mobile app does say “Synced” instead of “Saved” when it’s clear that it still haven’t sent all the changes upstream, correct?

Yes, it was saying Synced, not just Saved. I always wait for Synced to appear, before putting the app into the background. (And it’s time-consuming also because you always first need to press the menu button to see the sync status.) This time, even waiting for Synced didn’t help – although it was clearly saying Synced, the changes weren’t visible on desktop. Not just in one list – in several of them. I’ll let you know if I encounter this issue again in future.

As to how I refresh in the app – there’s a menu item for it in the mobile app. You press the three-dot menu button, and there’s a Refresh option. Only using this caused the app to finally submit all changes to the server.

Yes, the version history confirms what I’ve been reporting. I added a word to a list, but only the first two letters of that word got saved to the server at 2:47 p.m. (CET). Then at 3:14 p.m., after I returned to the app and performed the manual refresh, the rest of the word got synced as well. It was similar with another list – it took from 2:44 p.m. to 3:13 p.m. until everything from the mobile app appeared in the desktop version, but only after I manually refreshed the list in the mobile app, after half an hour.

(Yep, I realize the app is just a wrapper for the web version, but that’s how things are now. I sometimes see discrepancies on the same mobile device – when I open the same list in the app and in mobile Chrome.)

I see. The refresh option in the menu I believe just restarts the app (it does a page refresh instead of a full app restart). When the app starts up, it does a full sync with the server which is why it then sends everything.

Last question that I think could help with the investigation: Does it seem to happen more frequently when you make changes after resuming the app from background as opposed to starting the app from fresh? When starting the app fresh, you would see the splash screen for a short while and also a loader in the middle of the screen before your document appears. When resuming the app from background, you would see the last opened document almost immediately.

If you don’t remember that’s fine, I’m just curious to know in the future if you can look out for it.

Thanks again for being so patient with the investigation!

1 Like

No problem, I thank you for your help with this issue! :slightly_smiling_face:

I’m a heavy Dynalist user, so I pretty rarely start the app from fresh. I’m pretty sure that the issues observed today occurred after my resuming the app from background, as I was certainly using Dynalist on that phone even prior to 2 p.m.

So, I’ll try to be more careful from now on, and when resuming the app from the background, I’ll try to do a manual refresh before making any edits, and then again a manual refresh after I make changes. :unamused:

That can be annoying and time-consuming, but it’s better than data loss. It would really help if both the sync status and the refresh button were directly accessible in the app. (Without first having to tap the 3-dot menu button.) On the desktop, I always make sure to hit the F5 key to refresh Dynalist in Chrome before resuming work in it. (I never close Dynalist on desktop – the Chrome window with it is opened permanently on my desktop and notebook.)