Sometimes the v1 UUID generated by the second node has an earlier timestamp than the current schema UUID has.
Wouldn't that update be DOA then? I thought we checked to make sure the new migration compared after the current migration (as well as making sure the new migration's previous version matches with the current version).
A node shouldn't accept a schema change if the timestamp for the new schema would be earlier than its current schema.
If the clocks are that far off sync, I think the cluster has bigger problems (like writes not being applied). Plus, it would be easy for a node whose clock is way head to 'poison' schema updates from the rest of the cluster who are, in effect, behind the times.
Schema modification calls should accept an optional client-side timestamp that will be used for the v1 UUID.
Seems like a better approach.