At high speeds, writes become non-atomic

[inaimathi]

There's some threshold of evaluation frequency where cells with large on-disk representations end up partially writing. This destroys the notebook :/

Original README notes:

• BUG: When there's an error in a notebook we're loading, we do the "Notebook blah not found" thing. Instead, we should stop evaluating at that point and flag the offending cell. (Alternatively, we could also NOT load a notebook on open, but instead provide an eval-notebook function)
  • Had nothing to do with errors in notebook (those do actually get handled properly), this has to do with the approach for the trurl notebook, which ended up creating massive numbers of writes (it turns out that our storage approach isn't atomic under heavy enough load :/ This is going to be a deeper issue, and may percipitate the decision about moving to a non-fact-base storage solution)

[silent-entertainment]

@inaimathi

I was reading about websockets, when i came across something here that made me think of this issue.

Selenium WebDriver uses WebSockets to send scripts to the browser, and Chrome has a hard limit of about 1MB on WebSocket messages.

In another thread, you explained that it was only a problem when the cell was over 1MB in size.

Could you be hitting a hard browser limit or a server or sockets limit for the protocol that you're using and not seeing the problem in the log?