-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix for report of auto-save not working? #16798
Comments
I have been able to reproduce this behavior by turning off my computer's wifi connection, leaving it off for more than 2 minutes, then reconnecting and restarting the server. Any changes to the notebook in the server aren't saved, and the access/modify/change times of the notebook file don't change either. This doesn't appear to happen on our Jupyter instance running JupyterLab 3.6.x, so I'm wondering if this is caused by the changes introduced in #10156. |
@kellyrowland Thank you for opening this issue! It doesn't look like the patch mentioned in that Discourse thread ever made it into mainline code, but we would welcome a pull request to add it in. Please let us know if you need any help or find any other issues. Thanks again! |
@JasonWeill thanks for taking a look here - it's not at all clear to me what was actually suggested in the linked Discourse post, so I'm not sure about a PR just yet. @vkaidalov-rft could you weigh in on this as the author of #10156? I'm wondering if this check could be removed or if it would be preferable to decrease the save interval multiplier from 10 to something like 1.1. |
Thinking about this a little more, I don't think that changing the save interval multiplier would have any impact, because it seems that the call to
You can see here that I created I am not familiar with TypeScript, so I'm not sure why this callback is not getting set back to |
First, let me describe the problematic behavior here. The scenario is that a client is disconnected from a jupyter server running behind jupyterhub, and the disconnect is long enough that autosave has stopped from the client. After reconnecting, the kernel comes back, and the user gets the false impression that everything is back to normal. However, autosave has not resumed. So at this point, especially if you don't have the filebrowser open and notice that your notebook hasn't been saved, you will continue to work as usual, not realizing that the work has not been saved to disk on the backend. I also have a simple recipe for replicating the behavior using a vanilla jupyter repo.
If you click the save button, you can get the document to save, and that does kick off the autosave again. However, users will not realize they need to do this, and there is not a clear indication anywhere that 1) autosave is no longer happening and 2) a manual save is needed. This is a situation where information will be lost for unsuspecting users. |
Also, I should add that this behavior is different for direct to jupyterlab, locally, or in binder. When I tested jupyterlab with and without RTC enabled, without jupyterhub, I did not see this behavior with autosave. I have only been able to replicate it so far using jupyterhub and jupyterlab combined. |
Just had this issue affect us here - a user reported that his changes hadn't been saved after he reconnected when his wifi disappeared. (Thanks to @mlhenderson for the clear reproducible instructions above). |
hello - did the fix proposed in https://discourse.jupyter.org/t/auto-save-does-not-always-work/24756 ever get submitted (and merged into) JupyterLab?
I have gotten a similar report from a user on one of our Jupyter instances (JupyterLab 4.2.4, JupyterHub 5.1.0), though we have not been able to reproduce the issue.
The text was updated successfully, but these errors were encountered: