Bob locking doesn't work with comments, causing freezes

#1

I’ve been working on setting up a two-user wiki for myself and a friend this weekend. The Bob plugin has been super helpful (thanks to everyone who’s participated in that!).

To prevent collisions between different sessions, Bob locks a given tiddler when someone starts editing it. This has been working fine (aside from the fact that occasionally a lock doesn’t get released properly, but I know this is listed as a known issue, and it’s not hard to fix).

However, this doesn’t work when you edit a tiddler through, say, an $edit-text widget. I’m working on a custom version of the commenting plugin, and while I don’t have a good understanding of how all the pieces fit together, something here seems to be biting me constantly. I have two sessions running, one with each user logged in (by “logged in” I mean they use different HTTPS basic auth logins, and I’ve patched Bob to set $:/status/UserName based on a username header sent from an nginx proxy on each request). I’ll start typing a comment, which creates/edits a tiddler, and can see it updating in real time in the other window – and all of a sudden one of the instances stops sending or receiving from the server and the save button goes red, and cannot be revived except by reloading the page.

This would be merely be annoying, were it not for the fact that there isn’t any kind of error or immediate indication anything has gone wrong except for the button changing color. (Or rather: it’s clear to me because I have both sessions open side by side, but in a real-life situation where two people were editing simultaneously from different computers, it wouldn’t be.) So if you’re working in a narrow window or on mobile where you don’t immediately see the save button go red, you can end up doing a bunch of work which later gets lost or has to be manually reapplied.

Are there ways I can force some kind of lock here? Failing that, can I at least get an obvious error when syncing gets stuck? There’s no error message either in the server output or the console, so I’m not actually even sure what specifically is happening, much less how to hook something into it.

#2

I am incredibly new here, so anything I say now is a mere guess.

But you mentioned using an $edit-text widget. If that is a separate plugin from the bob plugin, then could you try if the problem occurs when you don’t use that plugin?

The other thing I noticed is the save button going red. As the other window gets more changes, this should occur at some point. But if the freeze always occurs when the save button goes red, then maybe those two events are related.

The second thing to try would be to type something on the first instance, save on the first, save on the second and repeat. If you avoid freezes that way then it is the save action on the second instance that needs looking into, and a solution might be a saver that works automatically.

I hope this would allow one step into isolating the bug (or feature).

#3

$edit-text is part of the core and underlies all text boxes in TiddlyWiki. You bring up a good point though – I don’t actually know if it is specifically the $edit-text widget, or anything that can change tiddlers, or some subset of things that can change tiddlers, so it might be worth trying to break it in a few more ways. I think the tiddler being edited has to be displayed in the other session at the time, but I’m not even 100% sure about that.

Ah – Bob saves automatically and continuously. So while it’s normal for the save button to occasionally flicker for a moment when changes are being made, it is not normal for it to actually turn red and stay red. That usually means the connection to the server has been lost, or in this case apparently that it has been blocked from sending more changes? (Though I don’t know the details because there is no error.)

#4

Thank you for the clarification.

One other thing occurred to me, as you have both sessions side by side on the same computer, it might be that the locking is going from one instance to the next, so that both are locked.

If it is possible to use 2 different computers or devices, that might also help to narrow the problem down.

Next thing to try is a nearly empty wiki, with only the bob plugin, to see if something else in the original wiki is causing it.

If the empty one does work, the bob part might not be the problem, and you could try adding tiddlers till it does break. Not a very practical solution if you have many tiddlers though.

If you use a windows computer you might want to look at the system load, for example when a virus scanner is not trusting the stream of information, you might see a spike in that just before it freezes.

Edit: one last thing, if bob locks the thread on one instance is the other instance maybe trying to write to a locked instance?

#5

I vaguely recall reports at one point that Bob struggled with scenarios where the sync interval was too low, such as can happen when editing a tiddler without using the drafts mechanism. Perhaps check to see if the issue still occurs when using the default UI for editing tiddlers.

#6

I don’t think it does when editing normal tiddlers. Would there be some way to reduce the sync interval? I don’t particularly care how fast it updates.

#7

You can throttle the sync by creating a tiddler called $:/config/SyncThrottleInterval, the default duration is 1000, i.e. 1s. Perhaps try setting it to 10000.

Polling interval should not matter but the setting for it is: https://tiddlywiki.com/#Hidden%20Setting%3A%20Sync%20Polling%20Interval

Here is the conversation I was recalling, note that I am unaware if this issue persists in current versions of Bob: https://groups.google.com/g/tiddlywiki/c/RA_4P0ST364/m/tkG-nOBLAgAJ

2 Likes
#8

Thanks for the link, that thread mentions single characters disappearing or getting corrupted, which is something I’ve also observed (usually right before saving gets stuck), so I’m guessing it is indeed the same issue.

I’ll give the sync throttling a shot.

Edit: This unfortunately did not work. It does slow down the immediate syncing of newly typed text, so it seems to be doing something, but it still gets stuck just as much.

1 Like
#9

I went in and rearchitected the comments editing plugin to use a half-baked draft tiddler mechanism (I only put the text field on them and only copy that field back when saving, because there’s not really any need for anything else). The comment still looks the same on the editing session, but I don’t show the editor for sessions that have a different username, so those sessions won’t see any update until you click the “save” button.

That appears to have fixed the problem, so I’m now quite confident that this is caused by the other session rapidly refreshing itself from the changes somehow. This obviously isn’t an ideal or complete solution though. In particular, it doesn’t address the case where the same user has multiple windows or devices showing the same tiddler; though there’s no obvious use case for this it could certainly happen accidentally quite easily. And there are presumably other ways this immediate-update situation could occur that would need to be dealt with one by one.

#10

One solution, although not optimal might be to have an extra field called current user or something like that.

This is 0 if nobody is using it, 1 for user 1, 2 for user 2, etc.

Only show Tiddlers with 0 or your own user number.

Then when editing first save your user number, and clear that when done. This might trigger a message if you want the other users to know, or you could keep a list of the currently visible tiddlers.

It might even be possible to give a list for all tiddlers, including the hidden ones, with only their current user visible, by coding an exception for that list.

The user number is generated for each instance. So with 2 users with 2 instances each, all editing, numbers 1 to 4 will be used.