Possible race conditions when syncing?

[balazshevesi]

Hello!

(I am quite new to local first, so i don't yet fully understand the intricacies of the problems in this space)

I was reading the docs, inspecting the network requests of an example app (SignalDB HTTP Replication Example - Todo App
) and trying to wrap my head around how syncing works when i discovered this:
When the client looses connection, preforms the usual CRUD operations, then connects again, all of the previously failed post requests get pushed all at the same time. In situations where the order of operations matter, this approach would breakdown very easily.

Does Signaldb provide an alternative solution? If not, are there plans to implement alternative solutions?

[balazshevesi]

I would be happy to contribute to contribute to the codebase, but i would need some guidance. I've already thought about how this could be solved.

One approach would be, what i call, the waterfall-solution, basically we would push the changes one by one to the server, only moving on to the the next push-operation when we've completed the current push successfully. The downside is speed, the upside is that we don't need to change anything on the backend.

The other approach would be to have a sync endpoint which signaldb would push to, it would essentially batch the operations into just one call. This is a much more elegant solution, however it would require the backend to be adjusted to accommodate it.

[maxnowack]

The SyncManager saves the changes together with a timestamp to "replay" the changes when the client is online again (main logic around these lines).
If you need to rely on the order, I would recommend find another solution. For example save a timestamp together with the data and send it also to the backend.
With distributed clients that can also be offline, you can never really ensure that data is sent ordered 😀