Story #7324
Updated by Rob Nahf over 8 years ago
In issue #3062, it was agreed that the CN should not be setting the authoritativeMN for an object, yet it still does for cases where those fields are null from the MN being synchronized, setting it using the nodeID in the associated syncTask (the systemMetadata's source MN).
The CN does need an authoritativeMN for further processing, but can we assume that the source node is the right one?
How does this jive with pre-replicated content (where there's already a replica on a member node) and the possibility of getting the replica before the authoritative? (what instructions have we given MNs who do this)
For example, if both MemberNodes have the same value for the originNode, but leave the authoritativeMN field blank, the authoritativeMN will be set to whichever node sync's first. It seems that if the originMN is passed in by the source node, and the authMN field is null, it should be populated with the same node as originMN, not the source node.
The CN does need an authoritativeMN for further processing, but can we assume that the source node is the right one?
How does this jive with pre-replicated content (where there's already a replica on a member node) and the possibility of getting the replica before the authoritative? (what instructions have we given MNs who do this)
For example, if both MemberNodes have the same value for the originNode, but leave the authoritativeMN field blank, the authoritativeMN will be set to whichever node sync's first. It seems that if the originMN is passed in by the source node, and the authMN field is null, it should be populated with the same node as originMN, not the source node.
