[Server v3] Strong coupling between client and server for certificates with equal timestamps

[vxgmichel]

At the moment, UserComponent.get_certificates() works by providing a starting timestamp for each topic as a *_after argument:

https://github.com/Scille/parsec-cloud/blob/7a7bd6b2221a198d5e92f08a5956ce6f853cb76f/server/parsec/components/user.py#L409-L418

That means that the server should return all certificates for the corresponding topic with timestamp greater than the provided timestamp. More specifically it returns the certificates with timestamps strictly greater than the provided timestamp:

https://github.com/Scille/parsec-cloud/blob/7a7bd6b2221a198d5e92f08a5956ce6f853cb76f/server/parsec/components/memory/user.py#L486-L489

The client uses it to get all the certificates that it doesn't already have locally by providing the timestamp of the most recent certificate it already has (for a given topic). However, certificates might have equal timestamps in some case, specifically for user and device certificates when a new user is created.

That means that a certificate might be skipped if a client happens to only have one of those two certificates locally. In practice, this should never happen because:

• the client is expected to accept or refuse certificates in batch
• AND the server is expected to perform user and device creation in one atomic step

However, this kind of pattern indicates a strong coupling between the server and the client. In particular, this problem might slipped unnoticed:

• if user and device creation are no longer performed in one atomic step
• if specific conditions in the client causes one certificate to be stored and not the other
• if new conditions for certificates with equal timestamps are introduced

Proper decoupling should be achieved by explicitly listing the simple rules and invariants that the client and server are expected to ensure (see more of that in #7120).

In this specific case, there are a couple of ways for simplifying those rules:

• Have get_certificates return the certificates greater or equal than the provided timestamp, while giving the responsibility of the client to ignore the certificates that might be already present locally.
• No longer allow for equal timestamps by forcing the clients to use a device certificate timestamp strictly greater than the corresponding user certificate. This means a strict ordering of all certificates in a topic.

Note:

Another way to deal with those issues is to index certificates from a given topic by using an ever increasing counter. This adds the extra property of being able to detect when a certificate is missing, although this kind of solution would require a lot of changes.

Yet another costly solution would be to add an identifier to the certificates which can be used by the client instead of a timestamp when requesting the certificates (e.g "please return all the certificates after the certificate for this given topic").

[mmmarcos]

At a first glance this does not seem a priority as it's unlikely that we'll come across a problem case.