nuprl/Ocelot

IDE fails to save file / run code after idle time

Opened this issue · 13 comments

This has been an issue for a while, reported by several users.
After some inactivity in the browser window, the IDE no longer behaves properly.
This typically involves

  • failure to autosave (thankfully signalled with a pop-up message)
  • (FIXED) failure to run the code when clicking "Run" button.
    Reloading the file fixes the issue, without need for re-authentication, but (obviously) changes may be lost, as per the warning. This did not seem to be an issue with the "old" Ocelot. Thanks for checking into it.

do you have a sense for how long I have to wait to witness this?

Sorry, I should have experimented and been more specific. I believe something like half an hour maybe. It has happened to me rather frequently, and several students have been reporting it, so it's not isolated.

For the second issue, I think that the program is still able to run correctly, but React failed to update and render the console properly.

https://github.com/ocelot-ide/Ocelot/blob/6887ff2/frontend/src/OutputPanel.tsx#L16-L42

Based on testing, I believe class ConsoleOutput is where the problem lies. React recommends each components to have unique keys, which help React identify which items have changed, are added, or are removed. But since there is no key in each ConsoleOutput instance, React cannot detect the changes.

Update: I found out that ConsoleOutput relies on console-feed to generate keys. By default, console-feed uses enumeration to generate identifiers, based on the object it was given at the time. This, however, has a side-effect when slicing the logs. If a console has 100 consecutive lines rendered with key from log-0 to log-99, then by adding another log line and slicing it, console-feed still sees it as 100 consecutive lines and renders with key from log-0 to log-99. The problem can be fixed by creating custom id tracker and adding custom id property to each Message before giving to console-feed

This is about the auto-save issue. I'll look into the console-not-refreshing problem in a bit.

I have not been able to reproduce the issue described. Here is what I did. I had Ocelot open in the background for several hours. I make edits to the buffer at 10:40AM, 11:50AM, and then again at 13:30PM. The file was successfully auto-saved at all times.

Let me know if you think I should do a different experiment. If not, would you just email me immediately when you encounter this problem again? Ideally, you would include the web browser console log. I'll look at the server logs to see what's up.

@dungwinux I'm pretty sure you're right. Thanks for the suggestion. I can prepare the fix. Or, would you rather submit a patch?

It should be possible to host Ocelot on localhost to test a change:

https://github.com/ocelot-ide/Ocelot/blob/master/frontend/package.json#L50

@arjunguha I can submit a PR.

I have one question: is it alright if I add an additional, zero-dependency package for the sake of id randomness?

You can. But, how about cycling through a set of IDs. I think scrollback is set to 100 lines. Would it be sufficient to cycle through 200 IDs?

I have to warn you: when it comes to code, if you ask me for an opinion, I will always have one. :)

But, just submit what you think is best and we can talk about it. One new dep is fine. Ocelot already depends on millions of packages. :(

@mminea I notice that Ocelot has a three hour maximum session length. Do you think you're witnessing this problem after three hours of inactivity? If that's the case, I can extend the session length.

On the other hand, if saving fails sooner than three hours, it's still a problem.

Oh, that would explain it. I have definitely revisited a window after more than three hours. I could imagine that students also keep a window open and work on and off. Perhaps extending the session length would be good. I'll watch out if saving fails after a shorter time, thanks!

I just updated the session length to 12 hours. I don't want to eliminate the session length cap. But, I think what's needed is a better message (e.g., you've been logged off, but don't worry, your work is all saved.)

So, I guess I broke my rule and made an update. But, it should really be "only" an update to the session length, so nothing should go wrong. Let me know if you notice anything.