substack/seaport — pull request #29 by mbrevoort (2013-04-10 02:38:42+00:00)
Title: crdt usage leading to unintended consequences

The synchronization of state between clients and server is leading to some unindented duplication and orphaning of data.

1. When a client disconnects from the server, the server is appropriately removing the service from the crdt set however the row is actually not getting removed from the crdt document and it remains in the history. When that client reconnects, and syncs with the server, all of the items in the history (even the one that's not part of the services set any longer), fires as a "register" even so that clients copy believes that there are still online services for services that actually went online. And this is causing duplicate entries for every stop/start of the client.

2. When the server is restarted, it gets it's state from the client. If the server itself registered any services, these are not properly unregistered and when the are synced from the client, queries to the server have duplicate entries for every time the server was stopped/started.

I've found a way around 1, but have a clarifying issue as to how to properly delete from crdt https://github.com/dominictarr/crdt/issues/21

Number 2 I don't have a solution for yet, and wonder in general with the way crdt is being employed here if it should be emphasized that the servers version of the state is authoritative. In the paste, before seaport was changed to use crdt, it worked very cleanly: the server would restart and all of the clients would reassert themselves.

I'm happy to continue to work through this, fix and pull request, but I need to better understand the intent and an agreed approach. What should happen to the state of things when the server restarts?