You are reading content from Scuttlebutt
@andrestaltz %xnrMoL1uoMMBepG4cre/fl4fO8U3RL/DHg/pF1b+480=.sha256
Re: %Kw9x8uLau

@happy0 👏 superb intuition for bugs! I was reading and was about to suggest cat([old,sync,new]) but saw that you wrote about that already.

About the race condition, it's possible that your intuition is correct, but we need to get hard evidence on that first. A test case would be great, and we have several test cases already. I hope our tests are well written so that it's easy to use them as examples and write a new one. In this case, we would need this tested in jitdb which is the module that does the actual logic for this specific live-vs-old concern.

Doing {sync:true} in jitdb would not be a quick and easy solution, because we need to modify the live function to support the old case, and that function is a bit of a monster. And even if we do that, we would still need a test case that makes sure that our changes solve the race condition. Otherwise, the addition of {sync:true} is no guarantee that it solves it.

So before we decide on which API is preferable (to have sync:true or not), I think it's important that we reproduce this race condition first. About the specifics of reproducing the race condition, we need to check what the gt byte offset threshold is in the live stream and check whether it matches the largest offset in the old case which is handled by paginate.

Join Scuttlebutt now