Code execution with older version after update

[prateek05]

Not very often updating the code in the frontend followed by execution leads to execution of the older code without the change though the frontend reflects the change in code and the backend confirms the commit was made before execution took place.
Prateek

[gordonwoodhull]

This is possible because of compute separation: one process is writing to GitHub and another process is reading independently.

My theory is that this is a race condition in GitHub as described in #32 and #329. But I haven't seen this behavior so I can't confirm it. In those cases, the result of the write showed the correct result but a read immediately after did not reflect the changes.

Their advice was to wait at least a second after writing before reading. It would be unfortunate to add a delay or confirm the read but perhaps we have to.

[s-u]

Compute goes through control, so in principle we could use the state in control, i.e., compute asking control to perform on its behalf with the option to cache. The additional benefit would be that compute doesn't need any credentials - for better or worse. It would require a modification of Rserve to allow control to expose its own OCAPs to compute (right now it just passes them through to the client).

[gordonwoodhull]

Yeah, we've discussed doing that anyway, because it's more efficient. I don't believe we have any caching right now, after the first write.

We just don't know if that's the actual problem here. Must devise a way to test this.

[gordonwoodhull]

I am seeing something very similar to this on chusuk right now, simply because the solr configuration is broken. So the updated notebook never "takes". Wonder if it could be something as simple as this, with errors either ignored by the front-end or ignored by the user.

[gordonwoodhull]

I added a check for the above condition, in the above commit.

Basically it nulls out the version while the commit is in transit - so if the promise chain is interrupted, or if it takes a long time and the user runs some cells simultaneously, they'll get a warning in the session pane:

Warning: executing unknown version, may be stale

It looks like null means it will always use the cached copy of the notebook - may be better to use some signal value which forces loading of the most recent version.

[gordonwoodhull]

Results of testing this for ~6mos: we do not see the bug all that often but there are still occasional complaints. We apologize, the user reloads and loses some code, life goes on but some confidence is lost.

We occasionally see the above error but the bug can occur without the error being printed.

It will be interesting to see if this is mitigated by the new gist server.