Hi Blake,
Thanks for your thoughts.
The reason I create those objects in a background thread is a comment I found from jens here:
Couchbase Lite 2’s query listener implementation runs the queries on the database’s default thread. If that’s the UI thread, it can degrade responsiveness. Workaround is to use a db instance that’s associated with a background thread.
I do have listeners on syncing, and I keep a state variable showing the current state of replication (in progress, idle, not started, offline, auth error etc) .
The reason I need to wait is that replication at endpoint A might complete, and then some time later (usually short) replication at endpoint’s B and C will start up and begin receiving A’s changes. Those changes might cause some “correction” changes to be propagated back. So I need to wait a period of time to make sure everything has caught up - even when replications say they are idle - there can be something that still needs to happen. Note that this is only for automated. testing - in the real world with apps on different devices, this is not a problem.
As to the question about sanity and determinism - that’s a really interesting topic (to me anyway). I have multiple endpoints sharing small “change” objects that represent a set of changes made to a large object held at the endpoints. This gives me efficiency (don’t swap the large object) and history. The challenge is sharing and merging those changes asyncronously at the remote ends, especially when the changes are conflicting. This has been a really interesting part of my research and is the reason I am creating this weird set of test cases. The bottom line is that I need to show that a set of changes created at remote endpoints and shared (synced) with each other, possibly out of order (or later if one endpoint is offline) has to result in the large object looking the same at all endpoints.
I still think that, given Jens comment above, there is something I dont understand going on, because live query or replication stops if the main thread is in a Thread.Sleep (or Task.Delay - I have tried making the test cases async, but that doesn’t help).
Cheers!
Paul