To recap the observations:
There is proof that the ability of coderoad to keep state depends on the user’s browser.
Coderoad can loose its state and when it does it starts afresh, however the tutorial state kept via git history is not lost. From that point on, Coderoad acts with a “split-brain”, showing the user a start screen text instruction and performing a test and validation based on the retained .mocharc.json git’s history.
It is possible to pay attention to only the failure warning and comply with it, but the history saved in git from that event is from the step that the screen text is showing, overriding the previous more advanced state.
Performing a git reset to the single point in time left initially, each time, you can advance the coderoad text screen by screen.
The “when” depends of at what point the process got broken. I wrote my observation not as a “fix” but rather as a behavior that can be reproduced.
I compare this effect to the same you can observe when watching a movie and suddenly the audio in no longer in sync with pictures in the screen. You can start playing with the audio, delaying it or speeding up by seconds with the hope you can trick it to sync. The result is never a fix.
It is my opinion that the end-user cannot recover the progress or “fix” the issue. It would be necessary for the end-user to know from where CodeRoad reads its state at start, which is independent of the history and files left behind by the user work and progress. Once CodeRoad fails to read some kind of progress state, it reverts to an init start and overrides the recorded history.
I have arrived to the conclusion that CodeRoad in itself (the code) might have bugs that facilitate the outcome of this effect that a lot of user are experiencing. However, it is very likely that this loss of progress comes due to the actual implementation of the environment via container-web-browser setup and logic.
Yeah, I went that rabbit hole sometime ago but yielded nothing relevant for Gitpod, since it doesn’t use that, unless you setup that variable. And it was more related to a problem of starting up properly.
The state of coderoad is saved in vscode via Memento API, according to its code.
Line 10 and 23.
It explains why when vscode looses the state of coderoad it starts anew, ignoring the previous progress based on the filesystem and creating the split-brain situation.
What I posted previously does confirm that statement. The actual implementation environment of using vscode with coderoad extension in a container-web-browser leads to the loss of the extension state, that otherwise would not happen.
