Dealing with ITS#9015 has lead me to question part of the ITS#8281 fix in cd8ff37629012c1676ef79de164a159da9b2ae89 - the part that refuses to generate a contextCSN on a DB without one.

When syncprov is adopting a database that has never been managed by it, it will only generate a new contexCSN if it's a standalone master (its serverID is zero and replicates from noone). But people can and do add a new database on a multimaster node expecting things to work OK, not something that happens now, even worse, we can lie to the consumer and say the DB is empty just because its contextCSN is.

AFAIK, the root cause of ITS#8281 (as reported) was diagnosed to be two servers with the same serverID - not something we can or want to support.

So my reaction is to make sure we always have a contextCSN (doesn't have to contain our own serverID yet), generating it if not unless we're running with SLAP_SINGLE_SHADOW(be) which means we might be a cascading replica.

Is there a scenario that would break things? How about starting with an empty DB, should we still put a contextCSN there?

Thanks,