Losing work during disconnection

[edemaine]

When the server is restarting, it's apparently possible to lose work. Actually, this seems to be possible more generally when having bad Internet connectivity; Meteor will keep trying to push results, unless you reload and lose those changes.

Perhaps we should detect server-disconnected state and give feedback (possibly even prevent drawing) in this case. Also perhaps ask about unloading in this scenario (like Coauthor).

[ndattani]

Thanks for creating the issue for me. I wasn't sure if it was significant enough to become an official "issue", so I just commented on the commit that seemed to cause the lost work. I wasn't even sure that it was a commit/deployment that caused me to lose the work, because it happened during a class and it was only hours later that I realized that a commit was made at that time. But now, the more I think about it, the more it indeed seems to be because of the deployment.

[ndattani]

I see there was a commit pushed into Master at around 3:30pm EDT today. I was teaching a class from 3-5pm and didn't lose my work this time, but I did find the drawing on the whiteboard to be slower than I've ever experienced it, and based on the noise the computer's fan was making, CPU usage seemed to be unusually high.

[ndattani]

Just now, tab 15 of my whiteboard was lost. While in the middle of a lesson, the whiteboard started refreshing, then when it refreshed tab 15 was lost. @FreedieTse was in the Zoom room at the time. Now I see that a commit was pushed about 22 minutes before this happened, so perhaps it was the same problem as last time? It doesn't look like I can get back what I had drawn in that whiteboard during a lesson. Do you suggest I run my own server?

[ndattani]

Tab 15 is back, but it's now Tab 14, and what used to be Tab 14 is now Tab 15. However, I lost everything on the tab that I was working on when this happened (i.e., what I drew in the last 14 minutes on a different Tab 15 which no longer exists).

[edemaine]

Running your own server would definitely be the safest/best option; there are no guarantees with this server. I was hoping your original experience was a one-time fluke (as it's really not supposed to happen — one of the servers should take over while another one reboots), but your most recent experience definitely sounds like a reproduction. (Your earlier slower drawing and fan noise would not be related to anything I did.) So I'll try to get a "disconnected" indicator working soon to avoid this in the future.

[edemaine]

@ndattani I wrote code that should substantially improve the behavior of future updates (after the update that's coming in a few minutes just deployed). Specifically:

• You'll now get a red notification at the bottom of the screen whenever you're disconnected from the server. In this state, anything you draw won't be sent to the server until a reconnection happens. I don't expect that this state happens for long, unless you have a bad network connection, but it is a prelude to the next state:
• You'll get a red notification at the bottom of the screen when the server has updated and wants to send you updated software to run. When you do so, it reloads the page, which may lose pending updates if they haven't had a chance to go to the server. The safe thing to do in this scenario would be to open the Cocreate room in another window/tab to see whether your changes have been uploaded, and once they have, you can safely reload the page to get rid of the red notice.

Let me know how it works out for you. Hopefully you won't lose any more drawings in the future.

[ndattani]

Thanks! We had the final exam period over the last two weeks, so I haven't been doing much teaching lately. I'll be using the cocreate whiteboard again in May, and will let you know how this works.

Another thing though: could the deployments be done at a time during which most users are asleep, such as midnight EST? This would be 6am in Europe and 9pm in California, therefore would avoid affecting most people's teaching in a lot of countries (though it would be 12pm in China).

[edemaine]

Do keep me posted on how the new feature works for you.

Restarting the server for deployment takes on the order of a second. It normally shouldn't cause any disruption, though clearly in your case it did for some reason — my best guess is it's because the page refreshed before flushing queued operations, so they got lost. Anyway, I'm hopeful that it won't be a problem in the future; now it should seamlessly reconnect and wait for you to confirm before updating. I need to monitor deployments so it needs to be done during my waking hours.

[ndattani]

I've now experienced this!

It's a little bit different from before, since the deployment this time didn't happen during my lesson. I had the whiteboard from last week's lesson open in a Chrome tab, and when I began teaching today's class I had the red notice at the bottom:

I think that I didn't lose any work (since I hadn't written anything new since last weak). However I did find this red warning message a little bit confusing. I followed the instructions:

• I clicked "visible in another tab" which created a new tab that seemed to contain everything from my last week's lesson.
• I didn't "select and copy" anything because there was nothing that was "recently changed"
• I then wasn't sure whether to click "Migrate to a new version" or "Migrate Now". Now I see that "Migrate to a new version" and "Migrate now" have the same hyeprlinks, but I wasn't able to figure that out in "real-time" when I was trying to start my lesson.

Also, once I've clicked "visible in another tab", do I not already have the "new version"? Basically, it seems that "visible in another tab", "Migrate now", and "Migrate to a new version" all take me to precisely the same URL, and the only difference is that the first one opens the URL in a new Chrome tab whereas the other two mutate the current tab.

If someone clicks "visible in another tab" and finds that no data has been lost (or manages to copy over any missing data), then is it really necessary to click "migrate now" or "migrate to a new version", which would just change the contents of the original tab into what we have in the new tab? Or can we just click "visible in another tab" and then close the original tab if nothing is missing?

[edemaine]

You're right: "migrate" just reloads the current tab, and "visible in another tab" opens the latest version of Cocreate in another tab. The point is to separate these actions: to avoid reloading the current tab until you've verified the content is there from another tab. You could instead close the original tab. I wrote this for you 🙂 but it's certainly cautious and wordy. I'm open to suggestions for improving the wording.

[ndattani]

Thanks very much for writing that warning message! In terms of suggested wording, how about something like this:

"The server wants to migrate to a new version of Cocreate; see the change log. for what's new. We recommend that you stop drawing, and check that your changes are visible in another tab of your web browser. If any drawings are missing, copy and paste them from here to the new tab, then close this tab and continue drawing in the new tab."

The phrase "tab of your web browser" is to avoid confusion with "tab of the Cocreate worksheet". You might have noticed that I used 18 Cocreate tabs in 1 single browser tab!

[edemaine]

Nice revision! Based on this, here's my current rewording; let me know what you think.

The server wants to migrate to a new version of Cocreate; see the changelog for what's new. You can click “Migrate Now” or reload to upgrade. If you've been drawing recently, you should first check that your latest changes are visible in another browser tab; if anything is missing, copy and paste from here to the new tab. Then close or migrate/reload this tab.

It still has the double migrate link, but now they have the same name, so maybe it's OK?