Possible race between save and navigation?

Theory: If a user navigates away from page beying edited before a pending save (debounced or waiting) completes changes may not be written to disk.

Facts: I happen to ran into this many times (I think, and cannot tell for sure, it’s just a “theory”). For example today… I was editing some Space Style and did some fast minor cleanup (replaced double quotes surrounding some value to single quotes). Then I navigated to Home page by pressing the home page button in the top bar and reloaded to check if everything is OK, …, and everything screwed up! :wink:

Because I already knew that this sometimes happen, I opened the page with the Space Style I was editing before in vi(1) from the command line and realized that the second double quote was still there! So only a half of my edit must had been saved!

It also looks like whenever I hit a key when editing, the page triggers some process leading to save it. It must be something about 2 or 3 seconds or so (not measured exactly, in fact, it’s my best guess I can tell about it).

It therefor looks like there is a serious race between navigating away from a page and it’s saving process.

If so, please add some guard to block page change (and similar actions) until all pending saves really complete (or some other method). I would also suggest to ensure the save is triggered on page change. Be there some hardcoded timing somewhere, make it customizable in configuration. Ensure that independent saving processess of the same content one at a time (if not yet guaranteed, I can not tell).

@zef I ran into the very same issue many times on v1, and I continue to run into it on v2 as well. Especially when it happens while editing on mobile it can be very annoying (I once edited something and I think I forgot some comma or something and was effectively left with broken Silverbullet until I got home and could use vi(1) to find and fix it manually).

3 Likes

I ran into this often especially when I use home action button, tree view links or links in page.

Now I am mindful of this and I end up navigating away from a page slowly ensuring enough time to save.

Not very convenient. It would be good to enforce a save while leaving a page. Is it even possible?

1 Like

Might be related to other race conditions e.g. here Indexing and System Readiness Issues - #2 by miro

Yeah, that will help. But it seems there is some serious flaw somewhere and it may be related to the hardcoded timing and lack of locking.

Another possibility is to warn user if she leaves a page and the page is not saved and let her confirm to save it. Generally speaking, be there a hook to page leaving would suffice to solve it. I have no idea if there is such.

There is still github for issues. Also it would be nice if you could try making it reproducible, otherwise it’s very hard to debug, because that’s the problem with race conditions, they aren’t just “there”. It’s also hard to know what “screwed up” means. The console output would be very helpful too.

About the actual problem. There is an autosaveinterval in SB, but the save only triggers, when the document has actually changed. The interval is 1s. I don’t see any reason for this to be customizable. It’s just added complexity.

And there is a save is triggered on page change, btw

OK. I described exactly how it usually happens. You edit a page and when you leave that page, typically to Home page, the page you edited before you left it, is screwed somehow. I have no idea how to make it reproducible, but it happens quite often, especially when editing things like Space Scripts in v1, Space Lua in v2 and Space Style, and it really feels like that it happens if you reach sub-three-second limit, or something like that. Therefor I have not filled GH issue yet but hoped others suffers from this as well so that we could discuss it here, get ideas and then fill exact issue to be fixed on GH, @MrMugame I will try to find something reproducible but thinking about it I would rather see some well-defined behaviour one could rely on, something proven to be safe. To wait some “safe” time seems as workaround, so it is about the timing, at least. On the other hand, I think @zef has some plans about the distributiveness SB, perhaps it just not worth the effort to fix this if it’s going to change in near future. The issue is a long-standing one. :slightly_smiling_face:

Something not being reproducible is still good to know. If it ever happens again (and I will say I had similar sounding stuff happen to me to, but I mostly use SB with questionable patches and plugs so I never investigated further) see if you can get the log from the console (this goes to everyone who experiences this more regularly). It can be very useful to see which events fired when, etc.

And what is “distributiveness”